Re: [TLS] Explicit use of client and server random values

[Mike Hamburg <[e-mail]>]

> On Dec 17, 2015, at 12:11 PM, Eric Rescorla <[e-mail]> wrote:
> 
> 
> 
> On Thu, Dec 17, 2015 at 3:02 PM, Hugo Krawczyk <[e-mail] <mailto:[e-mail]>> wrote:
> I have mentioned this in private conversations but let me say this here: I would prefer that the nonces be explicitly concatenated to the handshake hash.  That is, 
> 
> handshake_hash = Hash(
>                             client random            ||
>                             server random            ||
>                             Hash(handshake_messages) ||
>                             Hash(configuration)      ||
>                            )
> 
> The reason is that nonces are essential for freshness and session uniqueness and I want to see them explicitly included in the signed/mac-ed/KDF-ed information. I can envision a future variant/mode of the protocol where parties do not transmit nonces but have a synchronized state that they advance separately and use as nonces (e.g., for key refreshing) - in such case the nonces would not be included in the handshake-hash computation.
> 
> So while the redundancy of having them twice in the handshake_hash calculation may be annoying, this adds robustness to the security (and analysis) of the protocol.
>  
> This change doesn't make implementation or specification significantly more difficult.
> Does anyone  else object or feel it makes analysis harder? :)
> 
> -Ekr

While I haven’t been following TLS 1.3 development all that closely, I will question this request.

TLS is annoying to implement and analyze in part because it hashes more-or-less arbitrary parts of the handshake messages together, in arbitrary order, at arbitrary times.  Removal of all the explicit hashing of client/server random in TLS 1.3 makes it clearer what’s going on, and makes implementations simpler.  Some of the crypto operations still feel pretty arbitrary (particularly Finished), but things seem to be improving overall.  In this context, it feels like adding client random and server random back to the hash is a regression.

From an analysis point of view, the client and server random are parseable from Hash(handshake messages) because they are concatenated with framing information.  But here, they are concatenated without framing information.  So I don’t understand Hugo’s contention that the old scheme leads to trouble if the nonce changes sizes in a later version, and that the new scheme does not.  It seems to me that the reverse is more likely to be true.

Cheers,
— Mike