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/ > cryptographic random number generator serves no obvious purpose (all > that's required is a unique value), but exposes 224 bits of the > cryptographic RNG output to an attacker, allowing them to analyse and > potentially attack the RNG, and by extension any crypto keys that it > generates: > > o Implementations SHOULD NOT use the raw output from a > cryptographic/secure RNG that's used to generate keying material > to generate the Client.random and Server.random values. Instead, > they SHOULD employ a mechanism that doesn't directly expose > cryptographic RNG output to attackers, for example by using the > crypto RNG to seed a hash-based PRF such as the TLS PRF and using > the output of that for the values. > " > > I think something along these lines would be good advice to add > to appendix C.1 or to 4.1.2 where Random is defined.
I am not sure that this recommendation is practical. For one thing, it conflicts with the general advice that developers should not invent their own PRNG, and should use a good crypto RNG when available. 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? We want defense in depth, but in TLS 1.3 we mostly want to defend the private [EC]DH keys. So maybe the recommendation should apply there. Developers could for example mix the output of the crypto RNG with a locally held secret before generating the private keys. -- Christian Huitema
signature.asc
Description: OpenPGP digital signature
_______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
