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

[Nick Mathewson <[e-mail]>]

On Fri, Dec 6, 2013 at 2:59 PM, Wan-Teh Chang <[e-mail]> wrote:
> 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.

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