Re: [TLS] No more GMT exposure in the handshake

Jacob Appelbaum <> Sun, 08 June 2014 15:10 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 63B071A0423 for <>; Sun, 8 Jun 2014 08:10:48 -0700 (PDT)
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, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EJILOTvPwi7z for <>; Sun, 8 Jun 2014 08:10:47 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DC8D51A0420 for <>; Sun, 8 Jun 2014 08:10:46 -0700 (PDT)
Received: by with SMTP id z60so7764098qgd.37 for <>; Sun, 08 Jun 2014 08:10:46 -0700 (PDT)
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=BrvemEWQRlS3D5esKIPopH0ONZXpsCZuEIfmIx3F4VA=; b=eMYZMOx2eKxPOSRCicg3/47ioVSC4G3e1NgYUE9OyMurvWJDvUX4HFw7QUMAKH0jMT bVVy68TgfLK9EbF7zJ3zc4OI83WIJiKX0pwn6Mr2pnqx3wR9+1Y2WG2mgfMlSsa9GlCl 5ndgO9kJsS0pnSTIZNDLtZdV6iYabkCozgtSNWUzMPqx+Df9gXFRF8ExUasnpXj7SUbS IL6Lem6e0VFmj+eaK9Yqyvi7xz0tzGDKj8S3DiASExachtMrsKRjLb+/qaWyB3Fr1KaR rc4C+yhUplAkhwtEc6DP/aqXEz3QZF2occtURil/sArD40eZu2WACRRZLnwksBGhMOzA 5AgA==
X-Gm-Message-State: ALoCoQmsL6LfOQDiUR763++d4oG6ELf4OkGryi0G+7RuG253hWyRBeDxioBdai7A2BYw+oHntHVM
MIME-Version: 1.0
X-Received: by with SMTP id b9mr25924481qai.70.1402240246467; Sun, 08 Jun 2014 08:10:46 -0700 (PDT)
Received: by with HTTP; Sun, 8 Jun 2014 08:10:46 -0700 (PDT)
X-Originating-IP: []
In-Reply-To: <>
References: <> <> <> <>
Date: Sun, 8 Jun 2014 15:10:46 +0000
Message-ID: <>
From: Jacob Appelbaum <>
To: Kurt Roeckx <>
Content-Type: text/plain; charset=UTF-8
Cc: "" <>
Subject: Re: [TLS] No more GMT exposure in the handshake
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: Sun, 08 Jun 2014 15:10:48 -0000

On 6/8/14, Kurt Roeckx <> wrote:
> On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote:
>> On 6/7/14, Daniel Kahn Gillmor <> wrote:
>> > On 06/07/2014 10:56 AM, Watson Ladd wrote:
>> >> Putting the clock time in the TLS handshake enables fingerprinting.
>> >> It's useless cryptographically: 32 random bytes is exceedingly
>> >> unlikely to repeat.
>> >
>> > There seems to be a growing consensus on this point:
>> >
>> >
>> >
>> I've said as much to Nick and to Eric (in the context of working on
>> tlsdate[0]) but perhaps not on this tls list:
>> I'd like to see servers provide 64bits of time resolution in the
>> ServerHello and nothing but randomness in that field in the
>> ClientHello.
>> The current 32bit field isn't accurate enough for replacing NTP. If we
>> can't make the time field useful for accurate secure time exchange - I
>> hope we'll remove all network visible distinguishers, even ones that
>> are currently useful for totally bizarre reasons.
> Would that be in the same format as NTP, with 32 bit for the
> seconds and 32 bit for fractional second, and so a resolution
> of 0.2 nano seconds?  I'm wondering what kind of accuracy you'll
> get.

That sounds fine to me, sure. I admit, I haven't put a lot of thought
into the format because it seems that most of the momentum is in
removing anything meaningful from that field.

> Anyway, how do you plan to deal with checking the status of the
> certificate if you don't know what the current time is?

tlsdate has a bunch of options for that situation. I'd suggest
checking out how ChromeOS uses it as tlsdate is their default NTP-like
client for ChromeOS. It has short comings, of course.

With tlsdate, one may skip on checking the time and date constraints
for the first connection by setting some other constraints. As an
example, ensuring that the clock is moving forward while still having
assurances that an attacker must control specific cryptographic keys,

In any case, having 64bits of timing information from a server would
allow for a parasitic network time protocol that is as accurate as NTP
to be built on top of TLS. I haven't checked but I believe Google
still uses this to set clocks on ChromeOS.

I have a lot to say about tlsdate but it seems out of scope here.
Check out the code and please do help us to improve it!

All the best,