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

Brian Smith <> Fri, 06 December 2013 20:14 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 824731AE3A2 for <>; Fri, 6 Dec 2013 12:14:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.979
X-Spam-Status: No, score=-1.979 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MCh_JCb-2MPW for <>; Fri, 6 Dec 2013 12:14:44 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 745251AE3B9 for <>; Fri, 6 Dec 2013 12:14:44 -0800 (PST)
Received: by with SMTP id gc15so925476qeb.7 for <>; Fri, 06 Dec 2013 12:14:40 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=UkLfF5IIM1/Bic3B29ODJbX5/00dqQh7M0jZJ44nuLU=; b=RIF/MLk4R7UaiZdJHVrwcu99SEziubr+RiMj92ITiWkA5UtYlXX7QyCwulBMsF8iL8 5adYaPQf/0WIIHdcj2U0AYPUI8g0jp9Bid7CmpM/1LVHjZxcZd2KTURp4Z9gCzJC9EqF ZCiN9p0IsHOOXcooKYcB3CvJCaAMAm7SRukGAdBnV1ti7ZoMy1J0M+yJWJ5YgtH51OjF o7j7IttiwXbxCwlyZ0N6b2HfKl8Z8tNrB/bmdjmo6oJq7GlmyIbWDbnSMe0zNQ9r228Z uJNAxQKK+612sBf7Y+PzRtrY3gcnzpEY48lTlGGbKn+SdnHZzZO1renKgK/Vh4kPP3Cf kWmA==
X-Gm-Message-State: ALoCoQkxCx1b3Tlt7+JBzWYD/TzZWHPANnTJ/6KvMxZcKRAEMBl8E6vLud4szUZLzFxtLiminsqU
MIME-Version: 1.0
X-Received: by with SMTP id os1mr143314634qeb.39.1386360880551; Fri, 06 Dec 2013 12:14:40 -0800 (PST)
Received: by with HTTP; Fri, 6 Dec 2013 12:14:40 -0800 (PST)
X-Originating-IP: []
In-Reply-To: <>
References: <> <>
Date: Fri, 6 Dec 2013 12:14:40 -0800
Message-ID: <>
From: Brian Smith <>
To: Wan-Teh Chang <>
Content-Type: text/plain; charset=UTF-8
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: Fri, 06 Dec 2013 20:14:46 -0000

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

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

Mozilla Networking/Crypto/Security (Necko/NSS/PSM)