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

Kurt Roeckx <kurt@roeckx.be> Mon, 09 June 2014 15:08 UTC

Return-Path: <kurt@roeckx.be>
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 D22851A01BA for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 08:08:31 -0700 (PDT)
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, SPF_HELO_PASS=-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 tjjyVSlV6osu for <tls@ietfa.amsl.com>; Mon, 9 Jun 2014 08:08:29 -0700 (PDT)
Received: from defiant.e-webshops.eu (defiant.e-webshops.eu [82.146.122.140]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FA811A01BF for <tls@ietf.org>; Mon, 9 Jun 2014 08:08:29 -0700 (PDT)
Received: from intrepid.roeckx.be (localhost [127.0.0.1]) by defiant.e-webshops.eu (Postfix) with ESMTP id 4B5CF1C20BA; Mon, 9 Jun 2014 17:08:27 +0200 (CEST)
Received: by intrepid.roeckx.be (Postfix, from userid 1000) id 09E771FE01B4; Mon, 9 Jun 2014 17:08:26 +0200 (CEST)
Date: Mon, 9 Jun 2014 17:08:26 +0200
From: Kurt Roeckx <kurt@roeckx.be>
To: Alex Elsayed <eternaleye@gmail.com>
Message-ID: <20140609150826.GA9849@roeckx.be>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <ln29c9$qh4$1@ger.gmane.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/PXGoU4n3x3oGABrUPmnAQW7z2B8
Cc: tls@ietf.org
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 15:08:32 -0000

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.


Kurt