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

[Stephen Farrell <[e-mail]>]

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?
> 
> I’m glad you’re now agreeing that the above is a good plan.
> 

This discussion we had back in July was mostly motivated
by dual-ec. I think it's worth noting for the record that
we now have another instance of a very similar issue. [1]

Personally I think this argues for strengthening the text
we include in TLS1.3 to a RECOMMENDATION, in the body of
the document (as opposed to Appendix C.1 where it is now)
to separate the streams of randomness along the lines
described above.

The basic change would be to move the 2nd paragraph of C.1
to 4.1.2 where Random is defined, maybe to add a reference
to DUHK, and to insert a statement that implementers are
RECOMMENDED to put in place such separation. (I don't think
we need to say how they ought do that, as it's quite OS/RNG-
implementation dependent.)

I wonder if the new information (i.e. DUHK) convinces folks
that such a change is warranted?

If so, great. I'd be happy to submit a new PR or we could
re-open [2] or whatever. (I'd be just as happy that the
editor figure out the precise wording if that's easier.)

If not, I don't we need to debate this again, nor do we need
to hold up TLS1.3.

If the answer to the above isn't clear from the list between
now and the IETF meeting it might be worth asking the room
about this in Singapore if time permits.

Cheers,
S.

[1] https://duhkattack.com/
[2] https://github.com/tlswg/tls13-spec/pull/1068