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

Wan-Teh Chang <> Fri, 06 December 2013 20:38 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 742081AE19C for <>; Fri, 6 Dec 2013 12:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Status: No, score=-1.38 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id v_VaVHX1OVZo for <>; Fri, 6 Dec 2013 12:38:03 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c01::22e]) by (Postfix) with ESMTP id 1B7BB1AE191 for <>; Fri, 6 Dec 2013 12:38:02 -0800 (PST)
Received: by with SMTP id pa12so1377017veb.19 for <>; Fri, 06 Dec 2013 12:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Eottfo+eXr10nUdFYkxa2T9NxnCVXWB4+8QCjNs54B0=; b=LieSV457nwn0/O+EAy/SFHbslOyoCHGFpSaE5aFrssoABRoAHkztzp0Ab5/x/njN93 uPYD4yHvvgWqdYPZHpa1x5WMJuwMlzUOY7ZpN9Pnd9VYBv7Li1sDLoMdprRg77C8h/Sj zg6WHqUqd1qEAgCYqT/OXNMoTRnDZ1k9qTrmXyisuWz/ELnAJW/0zC/8uddiAt+aNqdT OLDJjU0ks2EPgiLZyr/E9xWLBpGasBf87iHLzqojrTEG60Ds6GYqiriLOXwufL/PN9nB Euj/sKimtDtZlbor39zhOhrTxpkRu7uiXodtO1TMm/gpTsn2lvAuRBC1f9oqx753V5VA H/yg==
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=Eottfo+eXr10nUdFYkxa2T9NxnCVXWB4+8QCjNs54B0=; b=kVgNkDgJM+YiUUBahfbX+7PO7MHMjnbhqnaxPJNOWqGT8HFJVFtZUzx/9W0FH4ouZT T3IcJh1Ejyz/PD8hJWpGUbKgS4oxHeUFKRgg/Cna0Jx09r/WnK5M7R3VDkDCBCF1A7IO CfuE4aKDtKwmHak2uMns7ujRv4x8yppBR6/SbG+IXjdESWqXQggn7Uj0heM2kKiF0yBQ olk7beNCFNMD9/qh0H5YILpBsWK1KPlZzq+0NJWIulKw5uL1vgLD0B3J0UjIS5aCAltn csph+FAcxkbE1Bn0iXhdv57bmLXLLVQ2wOkkIgmdzjqTkgRTEGaYxSu9ciykRx4Xhl+t pAeQ==
X-Gm-Message-State: ALoCoQnEcH6V0iavsvPs/GwDFxp++oLl2TyN3D9CLs2Gpim+s3Rgwo06udimzKOWm4scPIrT0rL3eqgiv9e4FBOpUcxq7XmH/vpcQJbRjAkkXG6AlbKHRGXhCjNjJJenhdztjflMzvemWMamiA48pkv8MyMcoNVtIkXELz2Ir6xu3ddITedyOiDiINiHfL5/ZNhwcwB43LnM
MIME-Version: 1.0
X-Received: by with SMTP id sa17mr2997983veb.14.1386362278915; Fri, 06 Dec 2013 12:37:58 -0800 (PST)
Received: by with HTTP; Fri, 6 Dec 2013 12:37:58 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
Date: Fri, 6 Dec 2013 12:37:58 -0800
Message-ID: <>
From: Wan-Teh Chang <>
To: Brian Smith <>
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: Fri, 06 Dec 2013 20:38:04 -0000

On Fri, Dec 6, 2013 at 12: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.

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.

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

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