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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 06 December 2013 20:16 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C7681AE167 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 12:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3a6RB1EjM_Ap for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 12:16:49 -0800 (PST)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) by ietfa.amsl.com (Postfix) with ESMTP id 76EB61AE107 for <tls@ietf.org>; Fri, 6 Dec 2013 12:16:49 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 27CDABEE9; Fri, 6 Dec 2013 20:16:45 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oxzNc8pm9KLs; Fri, 6 Dec 2013 20:16:43 +0000 (GMT)
Received: from [10.87.48.12] (unknown [86.44.77.181]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 7626ABEE8; Fri, 6 Dec 2013 20:16:43 +0000 (GMT)
Message-ID: <52A230A1.2000606@cs.tcd.ie>
Date: Fri, 06 Dec 2013 20:16:33 +0000
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1
MIME-Version: 1.0
To: Brian Smith <brian@briansmith.org>, Wan-Teh Chang <wtc@google.com>
References: <CAKDKvuw240Ug4xB3zi2w0y7pUvCwSe0nNFZ2XP2vL-tbtKT0tg@mail.gmail.com> <CALTJjxHGFqH+-C_9+Mr09zcNZ9HuW6XeeDNk4f+8vnMP0Tg5KA@mail.gmail.com> <CAFewVt4phoD-WUpV0iG0zdyBy1uqSa=meKhoGq12FOGVqXwvKw@mail.gmail.com>
In-Reply-To: <CAFewVt4phoD-WUpV0iG0zdyBy1uqSa=meKhoGq12FOGVqXwvKw@mail.gmail.com>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Cc: "tls@ietf.org" <tls@ietf.org>
Subject: Re: [TLS] Let's remove gmt_unix_time from TLS
X-BeenThere: tls@ietf.org
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." <tls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tls>, <mailto:tls-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tls/>
List-Post: <mailto:tls@ietf.org>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tls>, <mailto:tls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 06 Dec 2013 20:16:51 -0000

This [1] is probably also relevant.

S

[1] http://datatracker.ietf.org/doc/draft-mathewson-no-gmtunixtime/

On 12/06/2013 08:14 PM, Brian Smith wrote:
> On Fri, Dec 6, 2013 at 11:59 AM, Wan-Teh Chang <wtc@google.com> wrote:
>> 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.
> 
> 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.
> 
> 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.
> 
> Cheers,
> Brian
>