there was a discussion of adding a statement that a fresh ephemeral key MUST be
used for each session. It was decided not to do that. Without such a
requirement, nonces are needed.
Russ
> On Jul 24, 2017, at 12:40 PM, Dan Brown <danibr...@blackberry.com> wrote:
>
> Hmm, I'd appreciate a brief reminder* of why 1.3 needs nonces at all, given
> that ephemeral DH is mandated, if anybody has the time/patience. (* ok, not
> that I truly ever knew).
>
> I assume that the risk of misusing the nonces, to exfiltrate keys etc, is
> small enough compared to other side channels to justify their added value.
>
>
> Original Message
> From: Stephen Farrell
> Sent: Monday, July 24, 2017 11:15 AM
> To: tls@ietf.org
> Subject: [TLS] 32 byte randoms in TLS1.3 hello's
>
>
> 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
>
> _______________________________________________
> 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
