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

[John Foley <[e-mail]>]

On 12/16/2015 03:30 PM, Dave Garrett wrote:
> 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.
> .
>
Thanks for answering my questions.  Have you considered adding KAT 
values for the key derivation steps?  This would be helpful to 
implementors.  RFC5869 already has KAT values for HKDF-Extract and 
HKDF-Expand.  But the TLS 1.3 spec has added HKDF-Expland-Label. 
Additionally, It would be useful to show intermediate KAT values for 
xSS, xES, mSS, and mES.