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:-).
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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
