Re: [TLS] [perpass] Let's remove gmt_unix_time from TLS

[Nick Mathewson <[e-mail]>]

On Wed, Sep 11, 2013 at 12:04 PM, Russ Housley <[e-mail]> 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