On Tue, Jul 25, 2017 at 6:21 PM, Christian Huitema <huit...@huitema.net> 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 > applications and protocols sitting on top of TLS, such DTLS, QUIC or HTTP? > > They don't need to know or care about this, it's being used to generate the > TLS nonce which is invisible to anything running over TLS. > > Are we talking about the same thing here? > > > 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 OS API, > /dev/random or cryptogenrandom(), but that requires platform specific code. > The next natural thing to do is to reuse the random number generator > configured for the TLS context, because it is not OS dependent. If that is > not OK, then developers will need lots of explaining.
Why not write a cross-platform shim that calls the underlying OS specific API, instead of implementing another broken RNG? I feel the solution to broken RNG is don't use them. This entire discussion is premised on an idea that anything can be done about this "problem". > > -- > Christian Huitema > > > _______________________________________________ > TLS mailing list > TLS@ietf.org > https://www.ietf.org/mailman/listinfo/tls > -- "Man is born free, but everywhere he is in chains". --Rousseau. _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
