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

Nick Mathewson <> Mon, 09 December 2013 19:04 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7FDFE1AE4AD for <>; Mon, 9 Dec 2013 11:04:43 -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 XgFlXFy8KXuy for <>; Mon, 9 Dec 2013 11:04:42 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c00::232]) by (Postfix) with ESMTP id 17A7B1AE4AB for <>; Mon, 9 Dec 2013 11:04:41 -0800 (PST)
Received: by with SMTP id i13so2951060qae.9 for <>; Mon, 09 Dec 2013 11:04:37 -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:content-transfer-encoding; bh=juyj+WNuwCvlL80L/bmruS3aDVp9SH1WSUmXqv6Wf9k=; b=yfLcrvogy/LSyGe2pdFJqYXQI4AAwRT5wbrYIiG+IjqaX8WiAF0Xz5sTtoznvaiKp6 w+AoCRT8G1rsSa6pqvLTckSwscSTpO8+uiNf8+/G2Nj+ZVr17QoYcMbFBBXbJM1VfHdi 180gsdMhScNR/Q0SvAoinxzUR5C7QevgfLL/fNe+yTzX1a7PdQv6XU2gwU/V/shruN3U aEMLCM6dqlDt+QY2mBo25yJNrl8fMDoQDG3hYqSXkMxE0aCy1rUwRJCRXggkVwVbvIGK jcny68tqCBB9WPGjJmEx3UA1YvcG7mMj6HFc0DJwht1+BOD6CZM3uFM4tYKCH7lgHQJT GzWQ==
MIME-Version: 1.0
X-Received: by with SMTP id i1mr35618656qcu.13.1386615876977; Mon, 09 Dec 2013 11:04:36 -0800 (PST)
Received: by with HTTP; Mon, 9 Dec 2013 11:04:36 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Mon, 9 Dec 2013 14:04:36 -0500
X-Google-Sender-Auth: eVZ6lnYRcIPwc9-veDjBiKGOhwI
Message-ID: <>
From: Nick Mathewson <>
To: Brian Smith <>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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 19:04:43 -0000

On Fri, Dec 6, 2013 at 3:14 PM, Brian Smith <> wrote:
> On Fri, Dec 6, 2013 at 11:59 AM, Wan-Teh Chang <> wrote:
>> 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.
> 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.

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.

> 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.

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