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

[Mike Hamburg <[e-mail]>]

Whoops, big-R to reply all...

> On Dec 17, 2015, at 9:39 PM, Hugo Krawczyk <[e-mail]> wrote:
> 
> 
> On Thu, Dec 17, 2015 at 5:33 PM, Mike Hamburg <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 
>> On Dec 17, 2015, at 12:11 PM, Eric Rescorla <[e-mail] <mailto:[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. 
> 
> ​How does removal of explicit hashing of the nonces make things clearer? What are the things that are made clearer?
> 
> ​ 
>  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.
> 
> ​What do you mean by ​ ​"​ adding client random and server random back to the hash is a regression​"?
> Why "back"? Were they removed? What's the regression?
> You are probably not suggesting to omit them, right? Are you worried about the redundancy of being hashed twice? Is it a security issue or an implementation issue?
> ​.​
> 
> From an analysis point of view, the client and server random are parseable from Hash(handshake messages) because they are concatenated with framing information.
> 
> ​They are parseable, but I am not sure they are *uniquely* parseable - a fixed location in the stream does make them uniquely parseable.
> 
> ​ 
>  But here, they are concatenated without framing information.  
> 
> ​The nonces are the main framing information - they are the (honest parties') unique identifier of the handshake.
> 
> ​ 
> 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.
> 
> ​I'm clearly not following your argument.
> 
> ​Hugo
> ​
> 
> Cheers,
> — Mike

Sorry Hugo, I misread the proposal as using the nonces and handshake hash when signing, but not elsewhere.  On rereading, it is still entirely consistent, and isn’t being added “back” anywhere, except perhaps to some memory structure in the handshake code.  It also definitely isn’t a security problem, and it isn’t as annoying for implementations as I had figured (but it does require extra memory, which I had hoped to see removed).

However, I’m somewhat confused about your statement that the framing information is the honest parties’ unique identifier of the handshake.  I had thought that TLS 1.3 was going to a model where the handshake trace (and configuration, for 0-RTT) was the real session identifier, and the nonces were there exclusively to make that trace unique.  This is a huge improvement from TLS 1.2, where the session identifier is sometimes the nonces and sometimes the trace and sometimes something in between (Server Certificate Verify eg).  It further means that future versions could drop the nonces entirely if they require one-use ephemeral key exchange.  It seems that you’re suggesting that the session identifier is the tuple (nonces, trace, configuration), which seems redundant to me.  Perhaps it is required by the security model (eCK?) to have a stable session identifier?

I’m concerned about parseability in two ways.  One, if the nonces ever change size in future versions, or are omitted due to required one-use ephemeral key exchange, then we will have to change how handshake_hash is calculated, and we will have to make sure that it cannot cause problems due to collisions with the current handshake_hash calculation.

Two, if the handshake messages fed into the hash function are not uniquely parseable, that’s going to be a serious problem for analyzing TLS 1.3, and should be a top priority to fix.

Cheers,
— Mike