Subject: [ietf-tls] RE: On doing TLS 1.1

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 3 Jun 2001 17:11:02 +0300 (IDT)

On 31 May 2001, Eric Rescorla wrote:

> "Andreas Sterbenz" <[email-masked]> writes:
> > > What's wrong with the PRF function?
> > Some people on the list have argued that it is unneccessarily complex and I
> > tend to agree.
> Unfortunately, the reason it's so complex is that it was provided to
> us by Hugo's group and is therefore allegedly free of theoretical
> weaknesses. :(
> 

Eric, your memeory is wrong. That isn't the reason it is so complex.
Actually, back in 96 I was the one to oppose the mix of the two functions
especially that at the time the definition of the prf was using a mix that
actually gave you security of the WEAKEST of the two hashes rather than of
the best.

This issue was later resolved (to its current form) by the proposal of Dan
Simon to change the mix to a XOR of both hashes which does achieve the
property of having a PRF that remains secure as long as one of the two
hashes remains secure. Even then I thought it is overkill but only because
I speculated (and still do) that if one day SHA-1 is broken as a prf then
MD5 will probably be broken too or, at least, our confidence in it will
vanish.

For those interested in history I am attaching a note from Dan that I kept
in my folder where he makes his XOR proposal for the hash mix, i.e. the
one that was finally adopted in TLS 1.0 (note his reference to my advise
against the combination of two hash functions and our shared reservations:
"If it is still deemed necessary that the PRF's security depend on the
stronger of two hash functions rather than on just one...")

Coming back to the present (and even to the future) I have no problem with
the security of the current XOR-based mix, but if someone wants to go
to a single hash (for saving complexity) I would certainly not oppose that.

Hugo

The historical note by Dan Simon:

> Date: Wed, 12 Mar 1997 16:30:47 -0800
> Message-Id: <[email-masked]>
> From: Dan Simon <[email-masked]>
> Subject: RE:  WG LAST CALL for draft-ietf-tls-protocol-01.txt

[.....]

> Moreover, the actual choice of PRF defined in the spec (and based on the
> one used in SSL 3.0) has a couple of disadvantages.  For one, it relies
> on a newly defined "HMAC_mix" function which has not been defined
> previously elsewhere and is defined only sketchily in the draft.  More
> importantly, it is precisely the one which Hugo explicitly advised
> against, because the mixing of two hash functions in the PRF
> construction makes it dependent upon the security of *both* (rather than
> either) of them.  It would be better to define the PRF in terms of a
> single (replaceable) hash function specified by the cipher suite than to
> mix two functions in this way.  If it is still deemed necessary that the
> PRF's security depend on the stronger of two hash functions rather than
> on just one, then xoring the PRF outputs of two separate PRFs
> constructed from different hash functions (with each given different
> secrets as input) should suffice.

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

---

From: Hugo Krawczyk <[email-masked]>
Date: Sun, 3 Jun 2001 17:16:41 +0300 (IDT)

Another one...

On 30 May 2001, Eric Rescorla wrote:

> > I would suggest that this working group takes on TLS 1.1 and fixes the
> > (arguably) theoretical cryptographic weaknesses in the protocol and improves
> > protocol efficiency. My list of topics would include the Bodo Möller
> > handshake attack, MACing before encrypting (insecure according to Krawczyk),
> I'd like to hear an argument as to why MACing before encrypting is
> a problem. It's relatively standard practice.

It is quite standard practice but it turns out not to be a good one.
In a couple of days I will post my paper on the Web and then I'll write
a note to this list explaining a bit about the new findings.

Hugo

---

---

From: Eric Rescorla <[email-masked]>
Date: 03 Jun 2001 20:40:32 -0700

> actually gave you security of the WEAKEST of the two hashes rather than of
It depends where you believe the complexity lies. If you mean 
using both digests, yes, that's been there since SSLv3. However,
the PRF itself came from you (see your message of Friday, Dec 27
to ietf-tls). I've always viewed that as being the complex part,
but I can see how you would think differently.

-Ekr

---