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

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 6 Dec 2013 11:59:20 -0800

Sorry about my late reply. I am a programmer working on the NSS crypto
libraries. While reviewing recent changes to NSS, I noticed that
Nick's proposal 1 has been implemented in the OpenSSL and NSS source
code repositories, which led me to this old email thread.

The only protocol feature I know of that uses the gmt_unix_time field
of ClientHello.random is Adam Langley's TLS Snap Start Internet-Draft
[1]. See Section 3 of Adam's draft. This method is one of the
anti-reply mechanisms being considered in Eric Rescorla's TLS 1.3 new
handshake flows Internet-Draft [2], and is being used in the QUIC
protocol.

So, I'd like to offer another proposal:

PROPOSAL 4:

Add a random clock skew to the current time. For example, generate a
random signed integer in the interval [-512, 511] (inclusive) and add
it to the return value of time(). This adds roughly a +/-8.5 minutes
skew to the current time.

If this proposal is an acceptable solution to the client
fingerprinting problem, then gmt_unix_time in ClientHello.random will
remain viable as part of an anti-reply mechanism for TLS 1.3 new
handshake flows.

Wan-Teh Chang

[1] http://tools.ietf.org/html/draft-agl-tls-snapstart-00
[2] http://tools.ietf.org/html/draft-rescorla-tls13-new-flows-00

---

From: Brian Smith <[email-masked]>
Date: Fri, 6 Dec 2013 12:14:40 -0800

> skew to the current time.

When the server tells the client that it supports the 0-RTT handshake
scheme, can't the server also tell the client what time the server
things it is? Then the client could calculate the offset between its
local perception of the time and the server's perception of the time,
and apply that offset to whatever timestamp it sends in its 0-RTT
handshake.

Also, timestamps is only needed for the 0-RTT handshake, handshakes
that aren't attempting to be 0-RTT shouldn't include a timestamp. So,
the timestamps should probably be moved to the extension that
negotiates the 0-RTT handshake. That way, the fingerprinting risk,
whatever it is, is limited to applications that are actually trying to
use that feature, and applications/servers that are especially
sensitive to fingerprinting (e.g. the Tor Browser) may cleanly avoid
the issue by disabling 0-RTT handshake support, as a worst-case
option.

Cheers,
Brian
-- 
Mozilla Networking/Crypto/Security (Necko/NSS/PSM)

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 06 Dec 2013 20:16:33 +0000

This [1] is probably also relevant.

S

[1] http://datatracker.ietf.org/doc/draft-mathewson-no-gmtunixtime/

---

From: Wan-Teh Chang <[email-masked]>
Date: Fri, 6 Dec 2013 12:37:58 -0800

> and apply that offset to whatever timestamp it sends in its 0-RTT

I think this solution may also work. It is in fact that first solution
I considered. After I came up with the simpler random clock skew idea,
I stopped pursuing this further.

> the issue by disabling 0-RTT handshake support, as a worst-case

This is a good idea. However, this idea needs a little more work
because the timestamp must be part of the nonce input to the key
derivation function (the TLS PRF) in this anti-replay mechanism. So
the key derivation process for 0-RTT handshakes needs to also take the
timestamp in the 0-RTT handshake extension as input.

Wan-Teh Chang

---

From: Nick Mathewson <[email-masked]>
Date: Mon, 9 Dec 2013 13:49:15 -0500

> remain viable as part of an anti-reply mechanism for TLS 1.3 new

Hello, and thanks for thinking about this!

I'd suggest that this approach should be considered only with caution,
and used only when absolutely necessary (in other words, when 0-RTT
truly is in use).  If it can be avoided entirely, as with Brian
Smith's idea, it's probably better to do so.  If the timestamp can be
removed from the Random and added as encrypted data to a proposed
snap-start extension somehow, that's also an improvement, though an
imperfect one.

Random skew helps only a little:
   * It does nothing to conceal large drifts, which seem to be fairly
common in practice.  If two clients have drifted more than 1024
seconds apart, they'll remain completely partitioned.
   * Given multiple observations from the same client, it's trivial to
recover a good estimate of the client's clock skew and use that to
link other observations probabilistically to the same client.

On the latter point, I'd suggest that rounding is a little better than
adding random skew, since only a smaller fraction of a client's
declared times will leak anything about the client's skew.
Randomize-and-round might be better still, though I'm afraid I haven't
worked through the full analysis.

(As a reminder, using the time to avoid snap-start replays would be a
_new_ purpose for gmt_unix_time .  As discussed earlier in this thread
and in http://datatracker.ietf.org/doc/draft-mathewson-no-gmtunixtime/
, the gmt_unix_time is neither necessary nor sufficient for its
current declared purposes.)

peace,
-- 
Nick Mathewson

---

From: Nick Mathewson <[email-masked]>
Date: Mon, 9 Dec 2013 14:04:36 -0500

> and apply that offset to whatever timestamp it sends in its 0-RTT

This is a neat idea, and much more effective at randomization than at
hiding the client's view of the current time.

I believe that the QUIC crypto spec mentioned a similar idea (but
dismissed it in favor of another solution): "The first of these issues
could be addressed by having the clients take a clock-sync signal from
the server and define a “server local time” offset for that server."

One caveat here is that a server could tell different clients that it
had different skew values, thereby creating yet another way to set
stealth cookies.  You'd need to be sure not to share your view of
server-local time across anonymous sessions, while roaming in a
privacy-conscious way, and so on.

> the issue by disabling 0-RTT handshake support, as a worst-case

I'd agree that this is an improvement over sending gmt_unix_time to
everybody indiscriminately, surely, though you would (as Wan-Teh Chang
notes) need to change the inputs to the KDF a bit.  It doesn't seem
like an insurmountable obstacle by any means, though.

best wishes,
-- 
Nick Mathewson

---

From: Martin Thomson <[email-masked]>
Date: Mon, 9 Dec 2013 11:54:13 -0800

> worked through the full analysis.

It depends on what you believe you are protecting against, but if you
intend to protect against revealing the value of the local clock, then
neither is sufficient.  It all depends on how many samples your
adversary has available.

With rounding, all you need to recover the time is to watch for edge
crossings and align them.  With randomization, you ultimately reveal
time by hitting the limits of the random space.  9 bits of space
doesn't require a lot of samples.

If you want to do a really good job, then a 1-dimensional application
of the methods described in
http://tools.ietf.org/html/draft-thomson-geopriv-location-obscuring-01
would most likely work.  I'd probably go with full random before I
went there though - maintaining more secrets sounds like a good way to
get in trouble.

---

From: [email-masked] (Martin Rex)
Date: Tue, 10 Dec 2013 04:57:16 +0100 (CET)

> privacy-conscious way, and so on.

The server could also return client-specific session IDs in ServerHello,
or it could generate client-specific (EC)DHE public keys.

They is probably little you could do against a server that is
either subverted by some three-letter-agency or malicious all by itself.

-Martin