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

Nick Mathewson <> Mon, 09 December 2013 18:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 67A211AE3DE for <>; Mon, 9 Dec 2013 10:49:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.278
X-Spam-Status: No, score=-1.278 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id PnwcAdn_LmTY for <>; Mon, 9 Dec 2013 10:49:20 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c01::22c]) by (Postfix) with ESMTP id AA3721AE04B for <>; Mon, 9 Dec 2013 10:49:20 -0800 (PST)
Received: by with SMTP id e16so3050820qcx.31 for <>; Mon, 09 Dec 2013 10:49:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=i7motttgY8VTOBpCHJnSMF/IaVbJb3VUWoNZFAHk1p8=; b=yyeOAH/p7enW8KOlKnvuBT0IBEsvMmnqaco7QZZFblGAwLYM9/l4FVBx5ZBH9WKxqt vlRsLjcchH9SqekugqBbcK7qqZBMTCqyP+qVSRbAnpnCl5ZLm8N6HoO8wQaQO6B6Fxyp 6mFLhZeL4TBXkboa2nPNCDP3IKbeTKx/gWqTDCO0MziGsegLgJCyOBPIjqglxGpN5Gsu 6siltaWFXjJdHZwOXoBEYv28hYotPNI3XaIB1fyhovIUKAz1xgA1elIXxAElNXenWYsF ix9k9msWufJSQrpqxSCmf8UfAwt7U/h6mY78Sqbwg+UkI3PDidZQQIkGKNrdUJB1PKS+ tXFg==
MIME-Version: 1.0
X-Received: by with SMTP id e20mr186051452qej.63.1386614955680; Mon, 09 Dec 2013 10:49:15 -0800 (PST)
Received: by with HTTP; Mon, 9 Dec 2013 10:49:15 -0800 (PST)
In-Reply-To: <>
References: <> <>
Date: Mon, 9 Dec 2013 13:49:15 -0500
X-Google-Sender-Auth: 6IPXFbRb3OFYRZJ_wbr81euzEKA
Message-ID: <>
From: Nick Mathewson <>
To: Wan-Teh Chang <>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "" <>
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 09 Dec 2013 18:49:22 -0000

On Fri, Dec 6, 2013 at 2:59 PM, Wan-Teh Chang <> 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:
> 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
, the gmt_unix_time is neither necessary nor sufficient for its
current declared purposes.)

Nick Mathewson