Subject: [TLS] Results of interim meeting

From: Watson Ladd <[email-masked]>
Date: Mon, 26 May 2014 09:34:37 -0700

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?

Sincerely,
Watson Ladd

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 26 May 2014 12:40:05 -0700

> interim agenda. Is this a sign that the proposed fix for TLS 1.2 is

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.

No one present knew whether this mattered.

--Andy

---

From: Watson Ladd <[email-masked]>
Date: Mon, 26 May 2014 13:38:07 -0700

> 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.

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

-- 
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither  Liberty nor Safety."
-- Benjamin Franklin

---

From: Andy Lutomirski <[email-masked]>
Date: Mon, 26 May 2014 14:41:04 -0700

> the authorship of the paper explaining this flaw are 2006 and 2004

My possibly silly suggestion was to replace H(client hello || server
hello) with H(server random || client hello || server hello).  This
may make attacks on this considerably harder to mount.

--Andy

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 26 May 2014 14:49:47 -0700

> Finished message is computed with the concatenation of a SHA1 and MD5

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

> _______________________________________________
> TLS mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/tls
>

---

From: "Blumenthal, Uri - 0558 - MITLL" <[email-masked]>
Date: Tue, 27 May 2014 13:48:21 +0000

>  master_secret = PRF(pre_master_secret, "extended master secret",
Why not 

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