Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent

From: <[email-masked]>
Date: Fri, 12 Jan 2001 08:52:49 -0000

I think it would certainly be useful to re-visit the need for 2 hash
functions in MS generation in TLS version 2, whenever that happens.  I hope
we have MS generation on the SIM/WIM as part of wireless support of TLS, and
support of two hash functions on the smartcard would be something it would
be good to avoid.  (Sorry to keep banging on about limited client
capabilities)

Tim

> -----Original Message-----
> From: Paul Koning [mailto:[email-masked]]
> Sent: 22 December 2000 19:03
> To: IETF Transport Layer Security WG
> Subject: [ietf-tls] Re: Suggested Finished Message Processing
> Improvement
> 
> 
> I tend to agree with Eric that this is probably not a good time to
> make incompatible protocol changes.  
> 
> At the risk of being told to go back to the archives, I'll add another
> comment...  there seems to be a fair amount of opportunity for
> removing computational complexity from the protocol.  Right now it is
> very heavily biased to throwing lots of cryptographic functions into
> the mix to be very sure that there aren't weaknesses.  Other protocols
> (e.g., IKE) are much more minimalist, for example they never hash the
> same stuff with two hash algorithms.
> 
> Rather than tweak a single bottleneck now, how about revisiting things
> more globally for TLS V2.0?
> 
>      paul
> 
> 
> ---
> You are currently subscribed to ietf-tls as: 
> [email-masked]
> To unsubscribe send a blank email to 
> [email-masked]
> 

---
You are currently subscribed to ietf-tls as: [email-masked]
To unsubscribe send a blank email to [email-masked]

---

From: Eric Murray <[email-masked]>
Date: Tue, 16 Jan 2001 17:04:01 -0800

> be good to avoid.  (Sorry to keep banging on about limited client

Using two hashes also causes problems for high-performance TLS servers.  
I'd be also interested in examining the MS generation for possible
ways to streamline it and reduce the algorithm count when TLS v2 gets
going.

-- 
  Eric Murray           Consulting Security Architect         SecureDesign LLC
  http://www.securedesignllc.com                            PGP keyid:E03F65E5

---

---

From: Ben Laurie <[email-masked]>
Date: Wed, 17 Jan 2001 01:25:54 +0000

> Using two hashes also causes problems for high-performance TLS servers.

Perhaps you should consider upgrading from the Z80, then? Surely you
can't be serious about this?

Cheers,

Ben.

--
http://www.apache-ssl.org/ben.html

"There is no limit to what a man can do or how far he can go if he
doesn't mind who gets the credit." - Robert Woodruff

---

---

From: Eric Rescorla <[email-masked]>
Date: 16 Jan 2001 17:35:16 -0800

> can't be serious about this?
Actually, Eric's quite right. Once you optimize out the RSA operation,
the message digests for key expansion are the dominant performance cost.
When you get up around 1000 handshakes/s, the performance cost becomes quite
significant, even on fast processors.

-Ekr

---

---

From: Ben Laurie <[email-masked]>
Date: Wed, 17 Jan 2001 08:23:15 +0000

> significant, even on fast processors.

According to OpenSSL's benchmarks, MD5 is substantially faster than RC4,
and SHA-1 a touch slower. However, you have to RC4 substantially more
data, in general, so the dominant cost is surely the symmetric cipher
(not forgetting that other symmetric ciphers are generally slower than
RC4).

Cheers,

Ben.

---

---

From: Paul Koning <[email-masked]>
Date: Wed, 17 Jan 2001 11:26:08 -0500 (Eastern Standard Time)

>>>>> "Ben" == Ben Laurie <[email-masked]> writes:

 Ben> Eric Murray wrote:
 >>  On Fri, Jan 12, 2001 at 08:52:49AM -0000,
 >> [email-masked] wrote: > I think it would
 >> certainly be useful to re-visit the need for 2 hash > functions in
 >> MS generation in TLS version 2, whenever that happens.  I hope >
 >> we have MS generation on the SIM/WIM as part of wireless support
 >> of TLS, and > support of two hash functions on the smartcard would
 >> be something it would > be good to avoid.  (Sorry to keep banging
 >> on about limited client > capabilities)
 >> 

 Ben> Perhaps you should consider upgrading from the Z80, then? Surely
 Ben> you can't be serious about this?

What a strange comment.

Surely it is obvious that two hashes take twice as much processing as
one hash whether you use a Z80 or a Cray?  The only exception is if
you have hardware hash engines that are capable of hooking up the
various engines in such a way that both hashes can be done in a single
pass through the hardware.  It is possible to conceive of such
hardware but I have never seen any.

	 paul

---

---

From: Paul Koning <[email-masked]>
Date: Wed, 17 Jan 2001 11:32:14 -0500 (Eastern Standard Time)

Ben> Eric Rescorla wrote:
 >>  Ben Laurie <[email-masked]> writes: > Eric Murray wrote: > >
 >> Using two hashes also causes problems for high-performance TLS
 >> servers.  > > Perhaps you should consider upgrading from the Z80,
 >> then? Surely you > can't be serious about this?  > Actually,
 >> Eric's quite right. Once you optimize out the RSA operation, the
 >> message digests for key expansion are the dominant performance
 >> cost.  When you get up around 1000 handshakes/s, the performance
 >> cost becomes quite significant, even on fast processors.

 Ben> According to OpenSSL's benchmarks, MD5 is substantially faster
 Ben> than RC4, and SHA-1 a touch slower. However, you have to RC4
 Ben> substantially more data, in general, so the dominant cost is
 Ben> surely the symmetric cipher (not forgetting that other symmetric
 Ben> ciphers are generally slower than RC4).

It is a serious error to extrapolate like this from one benchmark of
one software-based implementation.  It doesn't necessarily apply on
other platforms, it doesn't necessarily apply with other
implementations of the algorithms.  And it most definitely has no
relevance whatsoever when analyzing hardware-assisted implementations.

My comment came from analyzing the performance issues with hardware
assisted TLS implementations.  It's clear that Eric R. is doing
likewise.  A software-only mindset is not helpful in making
appropriate design decisions here.

    paul

---

---

From: "Greg Stark" <[email-masked]>
Date: Wed, 17 Jan 2001 11:43:50 -0500

Let's not forget the MAC that occurs as part of the payload protection. This
means that every bit that gets encrypted also gets HMAC'ed, so the expense
of SHA1 or MD5 also creeps into the the payload protection part.

Greg Stark
Ethentica, Inc.
[email-masked]

----- Original Message -----
From: "Paul Koning" <[email-masked]>
To: "IETF Transport Layer Security WG" <[email-masked]>
Sent: Wednesday, January 17, 2001 11:32 AM
Subject: [ietf-tls] Re: Suggested Finished Message Processing Improvem ent

---

---

From: Eric Rescorla <[email-masked]>
Date: 17 Jan 2001 09:05:27 -0800

Ben Laurie <[email-masked]> writes:
> and SHA-1 a touch slower.
On my machines, substantially slower.

> However, you have to RC4 substantially more
Not really. You always have to digest more data than you encrypt.
It's true that you encrypt the plaintext + digest but remember that
we're not just using MD5. We're using HMAC, which means that you have
to digest at least 3 extra hash input blocks (the key twice and the
output of the first digest block. Since you don't pad with RC4, you're
always digesting more than you encrypt--this ignores the message
digest cost for the handshake.

However, the issue here isn't message processing. It's the amount of
time required by the digests in the handshake, specifically, the
additional time required by having to use MD5 and SHA-1 in parallel.
In the worst case, where the data being transferred is relatively
small the digest cost becomes quite significant. I misspoke when I
said it was dominant. It's more like 20-50% of the overall crypto
cost, depending on the size of the data records being transferred.

More importantly, it's difficult to optimize this stuff out with
hardware for the reasons that Eric indicated earlier. Basically,
the computation is so complicated that just having an RC4 or HMAC
core on your hardware doesn't help that much--whereas it does help
substantially for record processing.

As it happens, I don't agree with Eric that removing one of these
digests is a change worth making. We'd probably reclaim (at best) 20%
of the CPU and it introduces an incompatibility. IMHO, by the time
we've made the change, Moore's law will have done the job for
us. However, this doesn't change the fact that it's expensive.

-Ekr

---

---

From: "Andreas Sterbenz" <[email-masked]>
Date: Wed, 17 Jan 2001 18:34:58 +0100

I have had a look at the numbers. Results were obtained using our Java TLS
implementation connecting to jcewww.iaik.at:443 using
TLS_RSA_WITH_RC4_128_MD5.

Initial handshake:
MD5: 8384 bytes in 48 digests.
SHA-1: 7744 bytes in 42 digests.
(848 data bytes read, 280 written)

Abbreviated handshake:
MD5: 4964 bytes in 35 digests.
SHA-1: 4244 bytes in 29 digests.
(122 data bytes read, 173 written)

The numbers are total numbers of bytes processed, i.e. they include the
padding bytes. Also included are the operations done as part of the record
mac. The digest padding bytes actually make up a significant part but will
not need to be transferred over an external bus in many hardware
implementations.

A lot could be saved as well by changing the definition of the P_hash
functions to use something simpler that HMAC. HMAC is fairly expensive for
processing very short data as it requires two digest operations.

At the end the question remains of whether a change is actually worth it.
What seems fairly clear to me, however, is that the certificate accounts for
a fairly small part of the data. So it will not make much of a difference if
a precalculated hash is used, as was suggested recently.

 Andreas Sterbenz              mailto:[email-masked]

---

---

From: Ben Laurie <[email-masked]>
Date: Wed, 17 Jan 2001 18:47:16 +0000

> other platforms,

Did I say anything about which platforms that applied to?

> it doesn't necessarily apply with other
> implementations of the algorithms.

If people have some strange need to use slower implementations, that is
not my problem.

>  And it most definitely has no

Thankyou for the lecture. The supposition was that RSA was being done by
hardware, leaving the hashes and the symmetric crypto to be done in
software. I would be surprised to hear that the measured performance of
the symmetric crypto is less than that of the hashes in this case. Which
is the point I was trying to make.

Cheers,

Ben.

---

---

From: Ben Laurie <[email-masked]>
Date: Wed, 17 Jan 2001 18:50:26 +0000

> On my machines, substantially slower.

I may have been unclear: slower than RC4, not MD5!

> digest cost for the handshake.

I wasn't talking about the message digests, though I probably should
have been, thanks for the correction.

> cost, depending on the size of the data records being transferred.

Aha. So I was right :-)

> us. However, this doesn't change the fact that it's expensive.

Agreed. Just not dominant. I may have overstated my objection, I hadn't
realised how slow SHA-1 was. :-)

Cheers,

Ben.

---

---

From: Eric Rescorla <[email-masked]>
Date: 17 Jan 2001 09:15:12 -0800

> appropriate design decisions here.
We've already accelerated the RSA implementation but haven't accelerated
the MD5 and SHA yet. Have you? Did you gain performance or did the
bus overhead kill you?

-Ekr

---

---

From: Eric Rescorla <[email-masked]>
Date: 17 Jan 2001 09:19:24 -0800

> substantially for record processing.
This last paragraph is confusing.

What I meant to say is that just having an MD5 or SHA core on
the hardware means that you have to take a lot of trips across the
bus, which can be quite expensive. Obviously, having an RC4 core
on the hardware is only useful for record processing. That'll
teach me to write stuff first thing in the morning.

-Ekr

---

---

From: Paul Koning <[email-masked]>
Date: Wed, 17 Jan 2001 17:28:32 -0500 (Eastern Standard Time)

Ben> Eric Rescorla wrote:
 >> >> servers.  > > Perhaps you should consider upgrading from the
 >> Z80, >> then? Surely you > can't be serious about this?  >
 >> Actually, >> Eric's quite right. Once you optimize out the RSA
 >> operation, the >> message digests for key expansion are the
 >> dominant performance >> cost.  When you get up around 1000
 >> handshakes/s, the performance >> cost becomes quite significant,
 >> even on fast processors.
 >> 

 >>  It is a serious error to extrapolate like this from one benchmark
 >> of one software-based implementation.  It doesn't necessarily
 >> apply on other platforms,

 Ben> Did I say anything about which platforms that applied to?

No.  But the relative speeds of these algorithms definitely depends on
the instruction set.

 >> it doesn't necessarily apply with other implementations of the
 >> algorithms.

 Ben> If people have some strange need to use slower implementations,
 Ben> that is not my problem.

Well, some people do care about the performance of slow (low cost, or
more importantly, low power implementations).  But as it happens,
that's not what I was talking about.  I'm talking about much faster
implementations.  If you apply various accelerators, some algorithms
accelerate far more than others do (for example, typical crypto
hardware can do SHA-1 and MD5 significantly faster than RC4, which
makes sense if you consider what's involved.)

 >> And it most definitely has no relevance whatsoever when analyzing
 >> hardware-assisted implementations.
 >> 
 >> My comment came from analyzing the performance issues with
 >> hardware assisted TLS implementations.  It's clear that Eric R. is
 >> doing likewise.  A software-only mindset is not helpful in making

 Ben> Thankyou for the lecture. The supposition was that RSA was being
 Ben> done by hardware, leaving the hashes and the symmetric crypto to
 Ben> be done in software. I would be surprised to hear that the
 Ben> measured performance of the symmetric crypto is less than that
 Ben> of the hashes in this case. Which is the point I was trying to
 Ben> make.

My point is that you're objecting to a general proposal for optimizing
things, based on arguments that assume a particular supposition of
hardware vs. software, some (unstated) assumptions on the speeds of
engines and the performance requirements of the implementation, etc.
For the sort of systems I'm interested in, your assumptions do not
apply and the conclusions you draw from them don't either.

In particular, if you have hardware assists for all the crypto stuff,
then every additional crypto primitive is (typically) another pass
over the bus and another round trip through drivers and queues.  One
thing that's clear when you look at SSL/TLS key establishment: there's
a very large number of crypto operations being performed.  It seems
likely that a significant fraction could be taken out without damaging
security.  (For example, looking at IKE, I believe that it takes far
fewer crypto operations than TLS key establishment does.)

      paul

---