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.
_______________________________________________
TLS mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/tls
