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

Hiya, > Hasn’t this been the whole point of the discussion?! The proposal to > separate PRNGs into those that supply publicly-visible randomness > (nonces, etc), and those that supply “secret” randomness (keying > material and such)? Thus, having *two* PRNGs, each (hopefully) > properly seeded?

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

My guess is many TLS implementations don't have visibility into how the CSPRNG operates. That code does however, know which output values will be public and which not. For me, that implies that any good separation scheme applied within the TLS code that differentiates

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

-Original Message- From: Stephen Farrell [mailto:stephen.farr...@cs.tcd.ie] I don't think this is simply a case of multiple CSPRNGs. DB> Not quite sure what you mean by "simply a case of multiple CSPRNGs", but I am starting to get an idea below. My guess is many TLS implementations

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

es, but is plausible and relevant to the question at hand. (I thought I mentioned this earlier.) From: Colm MacCárthaigh Sent: Saturday, July 29, 2017 2:04 PM To: Dan Brown Cc: Stephen Farrell; Eric Rescorla; Blumenthal, Uri - 0553 - MITLL; tls@ietf.org Subject: Re: [TLS] 32 byte randoms in TLS1.3 hel

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

On Fri, Jul 28, 2017 at 01:37:33PM +, Dan Brown wrote: > > Finally, on systems with a linux-style interface, /dev/urandom and > /dev/random could be used as the two CSPRNGs on some systems (or > seed sources), although I think one of these is now deprecated? You do not want to use

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

although I think one of these is now deprecated? -Original Message- From: TLS [mailto:tls-boun...@ietf.org] On Behalf Of Stephen Farrell Sent: Friday, July 28, 2017 4:47 AM To: Eric Rescorla <e...@rtfm.com>; Blumenthal, Uri - 0553 - MITLL <u...@ll.mit.edu> Cc: tls@ietf.org

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

p and q, >> generated independently leading to an attack... >> >> Here if the seeds to initialize the RNGS are related, or one is weak, or >> worst if the seed is a raw source that doesn’t change in the moments >> between the two CSPRNG inits, that'd be bad, even

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

one is weak, or > worst if the seed is a raw source that doesn’t change in the moments > between the two CSPRNG inits, that'd be bad, even if the CSPRNGs were good. > *From: *Eric Rescorla > *Sent: *Thursday, July 27, 2017 6:34 PM > *To: *Stephen Farrell > *Cc: *tls@ietf.org > *Su

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

is weak, or > worst if the seed is a raw source that doesn’t change in the moments between > the two CSPRNG inits, that'd be bad, even if the CSPRNGs were good. > From: Eric Rescorla > Sent: Thursday, July 27, 2017 6:34 PM > To: Stephen Farrell > Cc: tls@ietf.org > Subject: Re: [TL

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

in the moments between the two CSPRNG inits, that'd be bad, even if the CSPRNGs were good. From: Eric Rescorla Sent: Thursday, July 27, 2017 6:34 PM To: Stephen Farrell Cc: tls@ietf.org Subject: Re: [TLS] 32 byte randoms in TLS1.3 hello's Spec updated here; https://github.com/tlswg/tls13-spec/commit

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

Spec updated here; https://github.com/tlswg/tls13-spec/commit/465de0e189b2b59090d0eac0acbc42942af9ca77 -Ekr On Wed, Jul 26, 2017 at 4:27 PM, Stephen Farrell wrote: > > I've suggested some text for this in a PR [1] > based on what people have said in this thread. > >

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

I've suggested some text for this in a PR [1] based on what people have said in this thread. I'm sure that can be further improved. It might be no harm to add more pointers to that appendix from elsewhere in the spec, and/or to add a list of the various public/private random numbers that are

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

On Wed, Jul 26, 2017 at 1:57 PM, Martin Rex wrote: > > Through the 10x compression of the RDRAND output, which will provably > create an incredibly huge amount of collisions, the attacker will be > unable to identify any particular output values of RDRAND. > > Your conceived attack

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

On Jul 26, 2017 1:57 PM, "Martin Rex" wrote: Colm MacCárthaigh wrote: > Martin Rex wrote: >> >> With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of >> a black-box CPRNG output into a 256-bit _new_ output that you >> actually use in communication

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

Colm MacCárthaigh wrote: > Martin Rex wrote: >> >> With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of >> a black-box CPRNG output into a 256-bit _new_ output that you >> actually use in communication protocols. > > If the relation between the RDRAND input

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

On Wed, Jul 26, 2017 at 11:58 AM, Martin Rex wrote: > With RDRAND, you would use e.g. SHA-256 to compress 10*256 = 2560 Bits of > a black-box CPRNG output into a 256-bit _new_ output that you > actually use in communication protocols. > If the relation between the RDRAND input and

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

Colm MacCárthaigh wrote: > Martin Rex wrote: >> >> Since you also have no idea whether and how the internal hardware design >> behind Intel RDRAND is backdoored, you should not be using any of its >> output without an at least 10x cryptographic compression in any case. > >

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

On Tue, Jul 25, 2017 at 9:21 PM, Christian Huitema wrote: > ... > Not sure. I am looking at the implementations of QUIC. QUIC needs its own > set of random numbers for things like connection ID or initial sequence > number. The most natural thing to do is do get them from the

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

On Wed, Jul 26, 2017 at 6:22 AM, Martin Rex wrote: > Since you also have no idea whether and how the internal hardware design > behind Intel RDRAND is backdoored, you should not be using any of its > output without an at least 10x cryptographic compression in any case. > Obviously

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

Peter Gutmann wrote: > Christian Huitema writes: > >>On 7/25/2017 4:57 PM, Peter Gutmann wrote: >>> Are we talking about the same thing here? >> >>Not sure. > > OK, I'd say we are :-). This isn't about which PRNG or randomness source to > use but the need for a

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

Christian Huitema writes: >On 7/25/2017 4:57 PM, Peter Gutmann wrote: >> Are we talking about the same thing here? > >Not sure. OK, I'd say we are :-). This isn't about which PRNG or randomness source to use but the need for a separation between PRNG-for-secret-values

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

On Tue, Jul 25, 2017 at 6:21 PM, Christian Huitema wrote: > > > On 7/25/2017 4:57 PM, Peter Gutmann wrote: > > Also, when we make such a recommendation in the TLS spec, we can hope that > it > will be heeded by the TLS developers, but what about the developers of >

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

On 7/25/2017 4:57 PM, Peter Gutmann wrote: >> Also, when we make such a recommendation in the TLS spec, we can hope that it >> will be heeded by the TLS developers, but what about the developers of >> applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP? > They don't need to

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

Christian Huitema writes: >For one thing, it conflicts with the general advice that developers should >not invent their own PRNG, You're not inventing your own PRNG, you're using the TLS PRF, or some equivalent (I use PBKDF2, HKDF is also nice). >and should use a good

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

On 7/25/2017 5:20 AM, Stephen Farrell wrote: > I guess you mean this: > > " >TLS-LTS drops the requirement to generate the Client.random and >Server.random using "a secure random number generator", typically the >one used to generate encryption keys. The use of a secure/ >

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

On Mon, Jul 24, 2017 at 11:15 AM, Stephen Farrell 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

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

On 25/07/17 04:53, Peter Gutmann wrote: > Colm MacCárthaigh writes: > >> I think the fix for this is really at the application level; if you >> want defense-in-depth against PRNG problems, it's probably best to use >> separate RNG instances for public data (e.g.

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

. 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

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

On Mon, Jul 24, 2017 at 8:29 AM, Watson Ladd wrote: > Don't use bad prngs. And don't buy products from vendors who ship back > doors and refuse to come completely clean when confronted. > Just yesterday DJB posted a blog post about AES-CTR-DRBG, one of the most

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

On Mon, Jul 24, 2017 at 8:15 AM, Stephen Farrell wrote: > 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 think the fix for this is really

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

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

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

On Mon, Jul 24, 2017 at 04:40:24PM +, Dan Brown 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). Two reasons: - The DH shares can be reused (even if

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

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

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

On Jul 24, 2017 8:15 AM, "Stephen Farrell" 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

[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