Re: [TLS] Results of interim meeting

[Eric Rescorla <[e-mail]>]

On Mon, May 26, 2014 at 1:38 PM, Watson Ladd <[e-mail]> wrote:

> On Mon, May 26, 2014 at 12:40 PM, Andy Lutomirski <[e-mail]>
> wrote:
> > On 05/26/2014 09:34 AM, Watson Ladd wrote:
> >> Dear all,
> >>
> >> It looks like most of the slides were devoted to SNI, and it is not
> >> clear what was actually decided.
> >>
> >> I haven't seen any slides about Triple Handshake, despite being on the
> >> interim agenda. Is this a sign that the proposed fix for TLS 1.2 is
> >> acceptable?
> >
> > There was a concern that the proposed fix might allow the client to
> > construct two different ClientHellos that would nonetheless result in
> > the same tls-unique value using the pre-TLS-1.2 PRFs.  The issue is
> > that, if you could find a SHA-1 collision, then MD5 is short enough that
> > it could be possible to do a length-extension attack and brute-force it
> > to be an MD5 collision as well.
>
> Yes, this is a problem. Basically the session hash needs to be
> computed with a secure hash, and TLS 1.1 and before don't use secure
> hashes.
> I don't think the proposed fix makes this issue worse: from my reading
> of TLS 1.1 and the tls-unique (should be renamed sometime) the
> Finished message is computed with the concatenation of a SHA1 and MD5
> hash of the messages.
>

To clarify, I believe the concern here was not directly about
the Finished messages (though they are perhaps implicated
as well) but about the key computation.

Specifically, in current TLS, the MS [0] and subsequently the
session keys [1] are computed as a PRF of the PMS/MS and
random values, specifically:


  master_secret = PRF(pre_master_secret, "master secret",
                           ClientHello.random + ServerHello.random)
       [0..47];


As the triple handshake paper observes, this allows an attacker
to force two handshakes to produce the same MS by duplicating
the PMS and the randoms. The current proposal is to replace the
random values with a hash of the handshake transcript, i.e.,

 master_secret = PRF(pre_master_secret, "extended master secret",
                       session_hash)
                       [0..47];

However if there is a collision in the function used to compute the
session hash, then this might allow an attacker to produce a
session_hash collision which might potentially reenable the attack
(and note that the attacker can potentially inject a lot of data here
through extensions).

-Ekr

[0] http://tools.ietf.org/html/rfc4346#section-8.1
[1] http://tools.ietf.org/html/rfc4346#section-6.3







How we fix it I don't know yet.
> >
> > No one present knew whether this mattered.
>
> It seems to me that this would be a problem, and is also a problem for
> the TLS 1.1 finished message for the same reason. The core issue is
> this: http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf.
>
> In short, with 64 invocations of the hypothetical SHA-1 break, then
> 2^64 MD5 calculations, you find a collision for the TLS 1.1 finished
> message. So the composite construction in TLS 1.0 and TLS 1.1 is no
> more secure than SHA-1. And yes, the dates of TLS 1.1 authorship and
> the authorship of the paper explaining this flaw are 2006 and 2004
> respectively.
>
> Sincerely,
> Watson Ladd
> >
> > --Andy
>
>
>
> --
> "Those who would give up Essential Liberty to purchase a little
> Temporary Safety deserve neither  Liberty nor Safety."
> -- Benjamin Franklin
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>