Thanks for the quick answers.
Yet more naive quick questions: in the reused DH setting could a counter do
the job of random nonce? doesn't the record layer have an IV or nonce too? (or
is that passe?).
If these questions are too naive, or too last minute, let me know and I'll
withdraw them. I did look over 1.3 once, fwiw, but have since forgot the
details, sorry.
Original Message
From: Russ Housley
Sent: Monday, July 24, 2017 12:58 PM
To: Dan Brown
Cc: IETF TLS
Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's
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
