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

[Michael StJohns <[e-mail]>]

On 7/21/2014 11:08 AM, Sean Turner wrote:
> 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.
>
>
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls
>
>

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