On Sun, Jul 03, 2016 at 09:22:27PM -0400, Dave Garrett wrote: > On Sunday, July 03, 2016 07:02:05 pm Eric Rescorla wrote: > > OTOH, those bytes will be more unique over time (because they are > > guaranteed not to repeat for a very long time after the second has passed), > > so intuitively this seems like a wash. > > Under the "Reevaluate handshake contents" part of the current TLS WG > charter [0], we have the question: "Are bigger randoms required?". Did > the WG ever fully discuss this and come to a decision?
I haven't seen a discussion. And my own opinion is "definitely not". However, shortening the randoms is different thing. And what makes this even nastier is that this isn't about what TLS 1.3 needs, but what TLS 1.2 needs. What does TLS 1.2 actually expect out of ClientRandom and ServerRandom? I think for ClientRandom, TLS 1.2 wants "Globally unique nonce". And for ServerRandom, "Nonce unique w.r.t. server key". TLS 1.3 has these a lot weaker: The "Globally unique nonce" from client is now the entiere ClientHello (and corresponding server nonce is the entiere ServerHello). If using DHE-type key exchange, both include short-lived public keys. (This actually comes from TLS 1.3 not using randoms for anything, causing some additional headache for contexts where privsep is needed). > Adding a > supplemental entropy extension would be trivial, if we wanted to > do so. Unfortunately, this only concerns TLS 1.2 mode on server-to-client direction, which is just about the nastiest case. - Can't stuff it in base ServerHello - Can't stuff it in any existing extension (I think at least some TLS clients do check that all lengths match exactly). - Can't stuff it in any new extension (not supported!) > (I see there was consideration of doing so a while ago [1].) BTW: The intended purpose of that extended-random was apparently to make exploiting DUAL_EC_DRBG easier (AFAICT, cuts down bruteforcing from 32 to 16 bits). The reasons stated for longer-than-256-bit randoms in that draft was likely to be cryptographically pretty bogus. -Ilari _______________________________________________ TLS mailing list [email protected] https://www.ietf.org/mailman/listinfo/tls
