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

[Dave Garrett <[e-mail]>]

On Wednesday, December 16, 2015 11:12:42 am John Foley wrote:
> I apologize if this topic was previously discussed, I've only recently 
> joined the TLS mailer list.  While reviewing the TLS 1.3 draft (revision 
> 10), section 7 begins with the following wording:
> 
>     In order to begin connection protection, the TLS Record Protocol
>     requires specification of a suite of algorithms, a master secret, and
>     the client and server random values.
> 
> However, when reading through all of section 7, there appears to be no 
> explicit use for the client and server random values.  While these 
> values would be used implicitly when the handshake messages are hashed, 
> and thus have bearing on the key schedule calculation, there appears to 
> be no explicit use of the client and server random values similar to 
> section 6.3 in the TLS 1.2 spec.
> 
> Am I interpreting this properly?

Yes, with the exception of the new downgrade protection mechanism that rides in the server random (in draft11 WIP), randoms are used implicitly via the handshake hash.

> If the client and server random values 
> are no longer explicitly used in any key derivation logic, maybe this 
> should be noted in section 6.3.1, as implementors will no longer need to 
> parse these values when processing incoming messages.  Additionally, the 
> intro to section 7 is misleading to implementors, as it implies the 
> client and server random values are needed to derive the key schedule.

There's still a lot of stuff with "TODO" notes on it in there that needs revision with regard to this. In particular, SecurityParameters still contains the randoms as well as the old master secret. I agree that this needs explicit explanation.

> The following issue and PR appear to be related to my question:
> 
> https://github.com/tlswg/tls13-spec/issues/185
> https://github.com/tlswg/tls13-spec/pull/189

Not really. The issue there was a suggestion to regen the randoms on retry request. Yes, it touches the randoms, but it's a tangential issue. In any case, the idea in question has been shelved.


Dave


PS
When referencing sections in the draft, please do so not just by number. Those can change as sections change. I suggest linking to one of the numbered drafts and citing its section, where possible. 6.3.1 is already different between draft10 and the current draft11 WIP.