Subject: [TLS] PR 508: Move downgrade sentinel to end

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Jul 2016 16:02:05 -0700

https://github.com/tlswg/tls13-spec/pull/508

David Benjamin has suggested moving the downgrade sentinel to the end of
the server random to avoid breaking tlsdate. This seems reasonable, as the
only real argument against is that conformant TLS 1.3 servers will have
only 20 bytes of entropy when doing TLS 1.2 compat (if they put the time in
the top 32 bytes), as opposed to 24 if they randomize the first 32 bytes.
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.

Barring any objections I'll merge this PR on Wednesday

-Ekr

---

From: Dave Garrett <[email-masked]>
Date: Sun, 3 Jul 2016 21:22:27 -0400

On Sunday, July 03, 2016 07:02:05 pm Eric Rescorla wrote:
> This seems reasonable, as the

to correct the typo: 32 bits / 4 bytes; total size of random is 32 bytes / 256 bits

> 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? Adding a supplemental entropy extension would be trivial, if we wanted to do so. (I see there was consideration of doing so a while ago [1].) Amending the TLS 1.3 spec to add it as a requirement would be easy, but would it be useful? If we want to allow 2 hacks in the current random value that reduce the entropy, then adding some entropy back in an extension makes some sense.

(If this was already settled at some point, please just point me to wherever that was. I might've just forgotten. ;)

Dave

[0] https://datatracker.ietf.org/wg/tls/charter/
[1] https://tools.ietf.org/html/draft-rescorla-tls-extended-random-02

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 4 Jul 2016 16:24:41 +0300

On Sun, Jul 03, 2016 at 09:22:27PM -0400, Dave Garrett wrote:
> 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