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

[Ryan Hurst <[e-mail]>]

I have looked at this some, network appliances such as F5s Big IP use a random value instead of time.

I recall seeing some clients also do this but I don't recall which ones.

Basically such a change should be safe.

That said as Russ has pointed out TPSDATE uses this mechanism and though it doesn't solve a broken cryptographic subsystem it is kind of belt and suspenders approach.

Ryan Hurst
Chief Technology Officer
GMO Globalsign

twitter: @rmhrisk
email: [e-mail]
phone: [phone]

Sent from my phone, please forgive the brevity.

On Sep 11, 2013, at 9:06 AM, Eric Rescorla <[e-mail]> wrote:

> Before we discuss mechanisms, it would be good to verify that in general
> clients and servers don't become unhappy if the timestamp is radically
> wrong. Has someone done measurements to verify that this is in fact
> the case at a broad scale?
> 
> -Ekr
> 
> 
> 
> On Wed, Sep 11, 2013 at 9:01 AM, Alfredo Pironti <[e-mail]> wrote:
>> I'm in favor of proposal 1, and second the considerations about it;
>> essentially, a broken crypto implementation cannot be fixed by a
>> timestamp.
>> 
>> If proposal 2 (and 3) was to be implemented on a server, it would also
>> make DoS easier, because a cheap ClientHello (even generated with weak
>> randomness) would trigger an extra HMAC computation on the server,
>> with respect to the current server load.
>> 
>> Hence, relying on PRNG on both client and server sides looks like a
>> reasonable way to go. I also don't particularly like the asymmetry
>> that proposal 2 may bring: client generating randomness with HMAC, and
>> servers still using the timestamp in clear.
>> 
>> Cheers,
>> Alfredo
>> 
>> On Wed, Sep 11, 2013 at 5:43 PM, Nick Mathewson <[e-mail]> wrote:
>> > Hi, all.
>> >
>> > Here's something I wrote about removing a fingerprinting opportunity
>> > from the current TLS protocol.  I was going to just send it to the tls
>> > list, but Ben Laurie suggested that I send it to the perpass list as
>> > well.
>> >
>> > I have little standards-body experience; if this ought to turn into an
>> > RFC or something, I'd be happy to write a draft if need be.
>> >
>> >
>> > (Tor currently plans to implement this by patching OpenSSL; any
>> > feedback or advice would be appreciated.  The first three approaches
>> > below are implemented in OpenSSL branches named "no_client_timestamp",
>> > "no_client_timestamp_v2" , and "no_client_timestamp_v3" in the git
>> > repository at https://github.com/nmathewson/openssl .  We have long
>> > shipped our privacy-enhanced browser with a feature like this enabled
>> > through an NSS patch.)
>> >
>> >
>> > ====
>> > SYNOPSIS:
>> >
>> > In TLS as currently specified, clients and servers each send their
>> > current view of "the time" in the clear as part of their handshake.
>> > This provides a fingerprint that can track users in spite of other
>> > attempts to make them untrackable.  I propose several ways to stop
>> > doing sending this cleartext timestamp; some trivial and some more
>> > complex.
>> >
>> >
>> > ACKNOWLEDGEMENTS:
>> >
>> > Thanks to Adam Langley, Ben Laurie, and everybody else who gave me
>> > feedback here.
>> >
>> >
>> > PROBLEM:
>> >
>> > The gmt_unix_time field in the Random field in the TLS handshake
>> > provides a way for an observer to fingerprint clients.
>> >
>> > Despite the late date, much of the world is still not
>> > synchronized to the second via an ntp-like service. This means
>> > that different clients have different views of the current time,
>> > which provides a fingerprint that helps to track and distinguish
>> > them.  This fingerprint is useful for tracking clients as they
>> > move around.  It can also distinguish clients using a single VPN,
>> > NAT, or privacy network.  (Tor's modified firefox avoids this by
>> > not sending the time.)
>> >
>> > Worse, some implementations don't send the current time, but the
>> > process time, or the computer's uptime, both of which are far
>> > more distinguishing than the current time() value.
>> >
>> > The information fingerprint here is strong enough to uniquely
>> > identify some TLS users (the ones whose clocks are hours off).
>> > Even for the ones whose clocks are mostly right (within a second
>> > or two), the field leaks a bit of information, and it only takes
>> > so many bits to make a user unique.
>> >
>> > Of course, I realize that the gmt_unix_time fingerprint is not the
>> > only way to track a typical client as it moves from network to
>> > network, and not the only way to distinguish different clients
>> > behind a NAT.
>> >
>> >
>> >
>> > BACKGROUND: WHY gmt_unix_time IN THE FIRST PLACE?
>> >
>> > According to third-hand reports (and correct me if I'm wrong!)
>> > gmt_unix_time was introduced in SSL 3.0 to prevent complete failure
>> > in cases where the PRNG was completely broken, by making a part of
>> > the Random field that would definitely vary between TLS handshakes.
>> >
>> > 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.
>> >
>> > Nevertheless, if the goal of providing unique-looking output
>> >
>> >
>> >
>> > WHY ELSE IS gmt_unix_time USED?
>> >
>> > The consensus among implementors I've asked seems to be that it's
>> > unwise to depend on any particular value or interpretation for the
>> > field.  The TLS 1.2 standard, RFC 5246, says that "Clocks are not
>> > required to be set correctly by the basic TLS protocol; higher-level
>> > or application protocols may define additional requirements."
>> >
>> > Some implementations set the entire gmt_unix_time field randomly;
>> > this appears not to have broken TLS on the internet.
>> >
>> > At least one tool (tlsdate) uses the server-side value of the
>> > field as an authenticated view of the current time.
>> >
>> >
>> >
>> > PROPOSAL 1:
>> >
>> > Declare that implementations MAY replace gmt_unix_time either with
>> > four more random bytes, or four bytes of zeroes.
>> >
>> > Rationale:
>> >    * Some implementations (like TorBrowser) are already doing this
>> >      in practice.
>> >
>> >    * It's sensible and simple.  Implementors are quite unlikely to
>> >      mess it up.
>> >
>> >
>> >
>> > PROPOSAL 2:
>> >
>> > Suppose that we do not accept the argument about the pointlessness
>> > of gmt_unit_time that I make above, and we want to preserve the
>> > security it allegedly provides.
>> >
>> > In that case, we can allow the following approach instead:
>> >
>> > Set the Random field, not to 32 bytes from your PRNG, but to the
>> > HMAC-SHA256 of any high resolution timer that you have, using 32
>> > bytes from your PRNG as a key.  In other words, replace this:
>> >
>> >    Random.gmt_unix_time = time();
>> >    Random.random_bytes = get_random_bytes(28)
>> >
>> > with this:
>> >
>> >    now = hires_time(); // clock_gettime(), or concatenate time()
>> >                        // with a CPU timer, or process
>> >                        // uptime, or whatever.
>> >    key = get_random_bytes(32);
>> >    Random = hmac_sha256(key, now);
>> >
>> > This approach is better than the status quo on the following
>> > counts:
>> >
>> >    * It doesn't leak your view of the current time, assuming that
>> >      your PRNG isn't busted.
>> >
>> >    * It actually fixes the problem that gmt_unix_time purported to
>> >      fix, by using a high-resolution time that's much less likely to
>> >      be used twice.  Even if the PRNG is broken, the value is still
>> >      nonrepeating.
>> >
>> > I do not think this is not worse than the status quo:
>> >
>> >    * It is unpredictable from an attacker's POV, assuming that the
>> >      PRNG works.  (Because an HMAC, even of known data, with an
>> >      unknown random key is supposed to look random).
>> >
>> >
>> > PROPOSAL 3
>> >
>> > As a hybrid alternative, one could set part of the ClientRandom
>> > field (perhaps 12 bytes or so) based on the HMAC of the time, and
>> > the rest of the ClientRandom field based on the PRNG:
>> >
>> >    N = 12
>> >
>> >    now = hires_time();
>> >    key = get_random_bytes(32);
>> >    mac = hmac_sha256(key, now)[0:N];  // First N bytes.
>> >    rand = get_random_bytes(32 - N)
>> >    Random = mac ++ rand               // concatenate.
>> >
>> > But this seems to be getting pointlessly baroque.
>> >
>> >
>> >
>> > CONSIDERATIONS:
>> >
>> > I'd personally suggest proposal 1 (just set the field at random) for
>> > most users.  Yes, it makes things a little worse if your PRNG can
>> > generate repeat values... but nearly everything in cryptography
>> > fails if your PRNG is broken.
>> >
>> >
>> > We might want to apply this fix on clients only.  With a few
>> > exceptions (like hidden services) the server's view of the current
>> > time is not sensitive.
>> >
>> >
>> > Implementors might want to make this feature optional and
>> > on-by-default, just in case some higher-level application protocol
>> > really does depend on it.
>> > _______________________________________________
>> > TLS mailing list
>> > [e-mail]
>> > https://www.ietf.org/mailman/listinfo/tls
>> _______________________________________________
>> TLS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/tls
> 
> _______________________________________________
> TLS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/tls