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

Alex Elsayed <> Sun, 08 June 2014 18:18 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5AD561A0102 for <>; Sun, 8 Jun 2014 11:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.477
X-Spam-Status: No, score=-0.477 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001, NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=1.164, RP_MATCHES_RCVD=-0.651, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_FSL_HELO_BARE_IP_2=0.01] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id j5jdWz2VmpKE for <>; Sun, 8 Jun 2014 11:17:58 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BA8101A00F8 for <>; Sun, 8 Jun 2014 11:17:58 -0700 (PDT)
Received: from list by with local (Exim 4.69) (envelope-from <>) id 1WthfI-0005Sa-M4 for; Sun, 08 Jun 2014 20:17:56 +0200
Received: from ([]) by with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Sun, 08 Jun 2014 20:17:56 +0200
Received: from eternaleye by with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <>; Sun, 08 Jun 2014 20:17:56 +0200
From: Alex Elsayed <>
Date: Sun, 08 Jun 2014 11:17:42 -0700
Lines: 56
Message-ID: <ln29c9$qh4$>
References: <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
User-Agent: KNode/4.13.1
X-Mailman-Approved-At: Mon, 09 Jun 2014 08:03:00 -0700
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 18:18:00 -0000

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.
> Anyway, how do you plan to deal with checking the status of the
> certificate if you don't know what the current time is?

32 bit seconds in new protocols is probably not a good idea, as 
Linux/BSD/etc are having to deal with now - 2^32 seconds is a bit over 136 
years, and while this use case will be unsigned (since it won't need to 
represent pre-epoch values, which cut time_t down to ~68 years) you're still 
going to run into something semantically identical to the Y2K38 problem. 
When that happens depends on what you pick as your epoch.

If you use it to transmit GPS time using that epoch, or UTC using the Unix 
epoch, then you will have some real problems.

The BSDs are switching wholesale to 64-bit tv_sec and 32-bit tv_nsec as I 
understand it; Linux is in the process of doing the same (but with stricter 
procedures on what's allowed to change ABI).

Similarly, you also probably want to consider exactly what time base you use 
- UTC brings in the mess of leap seconds, TAI avoids them but is subtly 
different and may surprise implementers who don't realize that.

In the end, I'd want to just chop it out - overloading TLS as a time-syncing 
protocol looks like the makings of a mess to me, since time handling is 
already quite messy.