Re: [TLS] 32 byte randoms in TLS1.3 hello's

On Jul 24, 2017 8:15 AM, "Stephen Farrell" <stephen.farrell@cs.tcd.ie>
wrote:

Hiya,

I'm guessing many folks interested in TLS may have been
at the QUIC session in Prague and hence missed out on the
excellent talk by Stephen Checkoway on the juniper dual-ec
incident. (I highly recommend taking a peek at the slides [1]
or reading the paper [2] or watching the video wherever
that may be;-).

Anyway, in TLS1.3 we've gotten rid of the gmt time option
in the client and server hello, which is good, (and I do
recall that discussion) but we've also changed from:

   // RFC5246
   struct {
      uint32 gmt_unix_time;
      opaque random_bytes[28];
   } Random;

to:

   // tls1.3 -21
   opaque Random[32];

Now if some TLS1.3 deployment were affected by a dual-ec
attack, it'd seem like the -21 version of Random might be
even better than the TLS1.2 version, for the attacker.

I tried to see where that 28->32 change came from but
didn't find it (apologies if I missed that). I guess it
just ensures that the overall length of the struct is
the same.

So, a question and a possible suggestion:

Q: Why do we need 32 bytes of Random?

Suggestion: if we don't need that much, maybe we could
change the length there, (I can see that might trigger
bugs and middlebox issues) or encourage/require folks
to mask out some of those bits (e.g. with zeros or some
catchy hex encoded message about dual-ec:-).

Anti-kleptography is not a matter of avoiding known attacks one at a time.
The fact is that someone could add backdoor login credentials or a buffer
overflow if they can also force dual-
EC to be used.

Don't use bad prngs. And don't buy products from vendors who ship back
doors and refuse to come completely clean when confronted.

Cheers,
S.

[1]
https://www.ietf.org/proceedings/99/slides/slides-99-irtfopen-anrp-stephen-
checkoway-a-systematic-analysis-of-the-juniper-dual-ec-incident-00.pdf
[2] https://web.eecs.utk.edu/~mschucha/netsec/readings/p468-checkoway.pdf

_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls