On Wed, Sep 11, 2013 at 12:04 PM, Russ Housley <[email protected]> wrote: > The tlsdate program (with origins in the TOR project) makes use of this value > in the nonce portion of the handshake.
That's true, and it's one reason that I would propose this as a client-only change (by default). > I think that the time is an important part of the nonce. Even if the > implementation has a crappy random number generator, the time value does a > good job of ensuring that the nonce value is not repeated. Obviously, the > time value does not help with the unpredictability, but the random value is > supposed to do that. I discussed that a bit in this part of my proposal: > I doubt that this goal is really achieved, for two reasons: > > * On modern desktop environments, it's not really so strange to > start two or more TLS connections within the same second. When > this occurs, the gmt_unix_time fails in its intended purpose of > preventing repeated Random values. > > * Nonwithstanding the gmt_unix_time workaround, TLS in general > does not withstand broken PRNGs. For one example, if an > implementation's PRNG is prone to repeating ClientRandom > values, it is probably prone to repeating those some values as > ephemeral Diffie-Hellman private values. In other words, sending gmt_unix_time in the clear will not save you from a bad RNG. (Later in the proposal, in the HMAC-based section, I explain how sending the gmt_unix_time in the clear is not necessary to save you from a bad RNG.) best wishes, -- Nick _______________________________________________ perpass mailing list [email protected] https://www.ietf.org/mailman/listinfo/perpass
