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

Alex Elsayed <eternaleye@gmail.com> Mon, 09 June 2014 22:32 UTC

Return-Path: <ietf-ietf-tls@m.gmane.org>
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 529A31A0285 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 15:32:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.477
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ApGcuX4YzbN7 for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 15:32:33 -0700 (PDT)
Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC5AB1A0263 for <tls@ietf.org>; Mon, 9 Jun 2014 15:32:32 -0700 (PDT)
Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from <ietf-ietf-tls@m.gmane.org>) id 1Wu878-0000Mk-Tp for tls@ietf.org; Tue, 10 Jun 2014 00:32:26 +0200
Received: from 50.245.141.77 ([50.245.141.77]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Tue, 10 Jun 2014 00:32:26 +0200
Received: from eternaleye by 50.245.141.77 with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for <tls@ietf.org>; Tue, 10 Jun 2014 00:32:26 +0200
X-Injected-Via-Gmane: http://gmane.org/
To: tls@ietf.org
From: Alex Elsayed <eternaleye@gmail.com>
Date: Mon, 09 Jun 2014 15:32:16 -0700
Lines: 54
Message-ID: <ln5clg$f53$1@ger.gmane.org>
References: <CACsn0cm69oJX_Bxqerig4qBmSf1fcQWW5EG42jia3qJkTwe0Tw@mail.gmail.com> <53934B47.4090603@fifthhorseman.net> <CAFggDF0rn+xuFksKW0+xJMAxRkjb8y6=7qiEQcM200iwtzy-0Q@mail.gmail.com> <20140608101721.GA6189@roeckx.be> <ln29c9$qh4$1@ger.gmane.org> <20140609150826.GA9849@roeckx.be>
Mime-Version: 1.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7Bit
X-Complaints-To: usenet@ger.gmane.org
X-Gmane-NNTP-Posting-Host: 50.245.141.77
User-Agent: KNode/4.13.1
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/gzgRLU6ydA-wrRQg8fWK-vtWLsU
X-Mailman-Approved-At: Mon, 09 Jun 2014 16:06:54 -0700
Subject: Re: [TLS] No more GMT exposure in the handshake
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: Mon, 09 Jun 2014 22:32:34 -0000

Kurt Roeckx wrote:

> On Sun, Jun 08, 2014 at 11:17:42AM -0700, Alex Elsayed wrote:
>> Kurt Roeckx wrote:
>> 
>> > On Sat, Jun 07, 2014 at 09:55:23PM +0000, Jacob Appelbaum wrote:
>> >> On 6/7/14, Daniel Kahn Gillmor <dkg@fifthhorseman.net> 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:
>> >> >
>> >> >   https://tools.ietf.org/html/draft-mathewson-no-gmtunixtime
>> >> >
>> >> 
>> >> 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.
> 
> Please note that NTP also uses the 32 bit for seconds, but has
> a concept of era's.  You basicly need to know that it's not 136
> years ago or in the future.

Yes, but TLS does not, hence my saying "in new protocols" (or new versions 
of existing protocols) - and in a very real sense, NTP's 'era' _is_ an 
extension of the time value beyond 32 bits; just in a way that splits it up 
somewhat strangely when we could just use a 64-bit value and thus handle it 
the same way as the operating systems we'd be using it on (64-bit seconds, 
32-bit nanoseconds).