On Jul 24, 2017 8:15 AM, "Stephen Farrell" <stephen.farr...@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
_______________________________________________
TLS mailing list
TLS@ietf.org
https://www.ietf.org/mailman/listinfo/tls
