Subject: [TLS] Call for adoption: draft-bhargavan-tls-session-hash

From: Sean Turner <[email-masked]>
Date: Mon, 21 Jul 2014 11:08:35 -0400

At the TLS interim meeting held Sunday the 20th of July 2014, we discussed adopting the following draft:

http://datatracker.ietf.org/doc/draft-bhargavan-tls-session-hash/

There was consensus to adopt it with the stipulation that the Signaling Cipher Suite Value (SCSV) be removed.  Please indicate whether you object to adoption (and why) by July 25, 2014.

spt

PS Stay tuned for an early code point assignment thread.

---

From: Watson Ladd <[email-masked]>
Date: Mon, 21 Jul 2014 08:19:39 -0700

On Jul 21, 2014 8:09 AM, "Sean Turner" <[email-masked]> wrote:
> There was consensus to adopt it with the stipulation that the Signaling
Cipher Suite Value (SCSV) be removed.  Please indicate whether you object
to adoption (and why) by July 25, 2014.

I cannot say: does this fix the key exchange or not? It is unclear from the
MiTLS papers, but because TLS is a mess I don't know if it fixes the
problem without the MiTLS proof.

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

---

From: Karthikeyan Bhargavan <[email-masked]>
Date: Mon, 21 Jul 2014 11:57:19 -0400

We have ProVerif-based analyses that show that the session hash fixes the triple-handshake problem for clients and servers that implement any combination of:
- TLS-RSA
- TLS-DHE
- Resumption with a Cache or Session Tickets
- Renegotiation with Renegotiation Indication
- SCRAM-SHA-1-PLUS with tls-unique channel binding

The analysis shows that, even if these features of TLS are implemented unchanged (i.e. arbitrary DH groups, no public key validation, renegotiation with any third-party, current definition of tls-unique), the TLS session hash guarantees composite agreement on the sequence of epochs on the current connection and also on their session parameters. The guarantee is similar to that of Giesen et al in CCS’13 [1] but extended to session resumption and extends to some other channel bindings like tls-unique and channel ID.

Having said that, our guarantees are in the symbolic model, and are not yet cryptographic proofs. Proof of the session hash implementation in miTLS is ongoing. 

Moreover, we cannot say anything about other ciphersuites, except to give general guidelines on what to watch out for. 

If there is interest, we’d be happy to make available our formal ProVerif models in some form and cite it within the current session-hash draft.

[1] https://eprint.iacr.org/2012/630

Best regards,
Karthik

On 21 Jul 2014, at 11:19, Watson Ladd <[email-masked]> wrote:

> I cannot say: does this fix the key exchange or not? It is unclear from the MiTLS papers, but because TLS is a mess I don't know if it fixes the problem without the MiTLS proof.
> 
> >
> > spt
> >

---

From: Alfredo Pironti <[email-masked]>
Date: Mon, 21 Jul 2014 17:57:32 +0200

Thanks for the update. As requested, I've uploaded an updated version with
SCSV removed.

Cheers,
Alfredo

---

From: Michael StJohns <[email-masked]>
Date: Mon, 21 Jul 2014 13:34:51 -0400

> PS Stay tuned for an early code point assignment thread.

How does this work with 1rtt?

E.g. the first message sent from the client side includes the 
ClientHello and embedded extension containing the ClientKeyExchange.  As 
I read this, the hash would then only cover that message.  (E.g. it says 
"up to and including ClientKeyExchange").

> When a full handshake takes place, we define
>
>           session_hash = Hash(handshake_messages)
>
>     where "handshake_messages" refers to all handshake messages sent or
>     received, starting at client hello up to and including the Client Key
>     Exchange message, including the type and length fields of the
>     handshake messages.  This is the concatenation of all the exchanged
>     Handshake structures, as defined in Section 7.4 of [RFC5246].

To be honest, I'm not a big fan of this approach as it requires the 
derivation of the master secret to be deferred until all the other 
exchanges are done and that seems to be counter to the move towards 
fewer round trips and prevents the ability to encrypt any of the 
handshake messages.

Or did I miss something here?

I would note that the attack on RSA encrypted secrets is not applicable 
to TLS1.3 as Key Transport as a pre-master mechanism is being removed.   
More detail expanding the DHE  (and ECDHE) attack would be useful.

Mike

---

From: Martin Thomson <[email-masked]>
Date: Mon, 21 Jul 2014 12:55:44 -0700

> How does this work with 1rtt?

There is an open question here, because the 1RTT handshake doesn't
allow for the master secret to cover the certificate.  The way that
the solution is formulated here (cover the server identity) isn't
compatible with an encrypted certificate.  We probably need some
analysis here, but the idea that was floated what that covering the
(EC)DH shares could be sufficient.

I think that's a separable concern and we should consider this draft
to be <= 1.2 only.  We can choose to use this solution, if it is
appropriate and can be adapted for 1.3.  However, as I understand it,
the current 1.3 structure doesn't allow this exact form for the fix.

---

From: Andrei Popov <[email-masked]>
Date: Mon, 21 Jul 2014 21:43:10 +0000

I agree with Martin on this, and also think more generally that TLS 1.3 should not rely on extensions to fix known problems such as triple handshake. Since the issue is known at the time of TLS 1.3 design, IMHO the fix should be an integral part of TLS 1.3.

-----Original Message-----
From: TLS [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: Monday, July 21, 2014 3:56 PM
To: Michael StJohns
Cc: [email-masked]
Subject: Re: [TLS] Call for adoption: draft-bhargavan-tls-session-hash

> How does this work with 1rtt?

There is an open question here, because the 1RTT handshake doesn't allow for the master secret to cover the certificate.  The way that the solution is formulated here (cover the server identity) isn't compatible with an encrypted certificate.  We probably need some analysis here, but the idea that was floated what that covering the (EC)DH shares could be sufficient.

I think that's a separable concern and we should consider this draft to be <= 1.2 only.  We can choose to use this solution, if it is appropriate and can be adapted for 1.3.  However, as I understand it, the current 1.3 structure doesn't allow this exact form for the fix.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 21 Jul 2014 17:52:07 -0400

> the current 1.3 structure doesn't allow this exact form for the fix.

Ok - that makes a bit more sense.  I've been overloading  the queries by 
Sean/Joe for adoption  as being solely fo TLS1.3.

I don't  have any great objections to adoption as a WG item as a 1.2 and 
before extension.  I think it's got a good bit of work necessary before 
submission as an RFC though.

Mike