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

Wan-Teh Chang <wtc@google.com> Fri, 06 December 2013 20:38 UTC

Return-Path: <wtc@google.com>
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 742081AE19C for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 12:38:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.38
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v_VaVHX1OVZo for <tls@ietfa.amsl.com>; Fri, 6 Dec 2013 12:38:03 -0800 (PST)
Received: from mail-ve0-x22e.google.com (mail-ve0-x22e.google.com [IPv6:2607:f8b0:400c:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 1B7BB1AE191 for <tls@ietf.org>; Fri, 6 Dec 2013 12:38:02 -0800 (PST)
Received: by mail-ve0-f174.google.com with SMTP id pa12so1377017veb.19 for <tls@ietf.org>; Fri, 06 Dec 2013 12:37:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; 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; d=1e100.net; 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 10.58.143.17 with SMTP id sa17mr2997983veb.14.1386362278915; Fri, 06 Dec 2013 12:37:58 -0800 (PST)
Received: by 10.52.167.10 with HTTP; Fri, 6 Dec 2013 12:37:58 -0800 (PST)
In-Reply-To: <CAFewVt4phoD-WUpV0iG0zdyBy1uqSa=meKhoGq12FOGVqXwvKw@mail.gmail.com>
References: <CAKDKvuw240Ug4xB3zi2w0y7pUvCwSe0nNFZ2XP2vL-tbtKT0tg@mail.gmail.com> <CALTJjxHGFqH+-C_9+Mr09zcNZ9HuW6XeeDNk4f+8vnMP0Tg5KA@mail.gmail.com> <CAFewVt4phoD-WUpV0iG0zdyBy1uqSa=meKhoGq12FOGVqXwvKw@mail.gmail.com>
Date: Fri, 6 Dec 2013 12:37:58 -0800
Message-ID: <CALTJjxG-d9efpnPncvo5qB2qRoaOBZY2JJSFjGM4h2-ByRWUpw@mail.gmail.com>
From: Wan-Teh Chang <wtc@google.com>
To: Brian Smith <brian@briansmith.org>
Content-Type: text/plain; charset=ISO-8859-1
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:38:04 -0000

On Fri, Dec 6, 2013 at 12:14 PM, Brian Smith <brian@briansmith.org> 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.

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