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] presentation language description is not great

I don't think it's useful to rework the PDUs significantly. That's a great way to really mess things up. If you think that there are changes to the *description* of the language that would make it easier to read that description and then read the PDUs, PRs might be useful. Also, very small tweaks

Re: [TLS] presentation language description is not great

I agree with Ben. It is too late On 07/26/2017 06:51 PM, Benjamin Kaduk wrote: > On 07/26/2017 10:59 AM, Stephen Checkoway wrote: >> My motivation for all of this is it would be nice to have a clean PL that is >> easily machine parsable. This would enable ensuring that future changes to >> TLS

Re: [TLS] presentation language description is not great

On 07/26/2017 10:59 AM, Stephen Checkoway wrote: > My motivation for all of this is it would be nice to have a clean PL that is > easily machine parsable. This would enable ensuring that future changes to > TLS (e.g., extensions) use a consistent syntax. It would also enable (at > least in

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

[TLS] presentation language description is not great

Stepping back a bit from my previous messages on `select`, I took a broader look at how the presentation language (PL) is used to define the bits that get sent over the wire. In essence, the presentation language defines types and encodings of types. At a high level, there are 46 types that

Re: [TLS] TLS 1.3 presentation language

> On Jul 26, 2017, at 03:08, Kazu Yamamoto (山本和彦) wrote: > > Hi Stephen, > >> Initially, I thought proposal I would be the best, but now I have a >> mild preference for proposal III. I think it makes the language >> simpler over all. It essentially becomes two primitive types

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] TLS 1.3 presentation language

Hi Stephen, > Initially, I thought proposal I would be the best, but now I have a > mild preference for proposal III. I think it makes the language > simpler over all. It essentially becomes two primitive types > (`opaque` and `uint8`) and four type definitions: I like III, too. But I don't