Re: [TLS] More hello entropy? (was: PR 508: Move downgrade sentinel to end)

[Ilari Liusvaara <[e-mail]>]

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