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

Jacob Appelbaum <jacob@appelbaum.net> Sun, 08 June 2014 22:19 UTC

Return-Path: <jacob@appelbaum.net>
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 0E67B1A03F2 for <tls@ietfa.amsl.com>; Sun, 8 Jun 2014 15:19:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.978
X-Spam-Level:
X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-0.7] 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 vwZnWwATa1JR for <tls@ietfa.amsl.com>; Sun, 8 Jun 2014 15:19:32 -0700 (PDT)
Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 02F691A0192 for <tls@ietf.org>; Sun, 8 Jun 2014 15:19:31 -0700 (PDT)
Received: by mail-qa0-f41.google.com with SMTP id dc16so7206114qab.14 for <tls@ietf.org>; Sun, 08 Jun 2014 15:19:31 -0700 (PDT)
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:content-type; bh=ijBsAeMiDKk3de1myBqONRXJBRUSeXo3U+FGLtyknzM=; b=dQS+ZtCS3MjH3GguHn0Hjo4eJrPk34BK/howiiELWNDB1ZdtzWtu+axo4tJOM7CYvu BNA7lYpgngEu2GwHvAkJDvCDCZyAtOvSZXD+Db0nhmgZX7Z6e2+4nHl9bteAg6wyhWVS PvYEPBej2+etgpHPnwWWjJCiDfxB840//66CKPaG15fv+f5J1O7SAoJlQh6IhuPtCGgb ZO0IDxbvOXXQpFyLiEweAL29cNoC63yEp9abqSzJ0GwnjovuQmidswetxF4X7h14qn63 dWSZG6lsUfSwLR9+EP61WZoX8GA3o0OPA0F+Tahc+8GTPHtEbsoIFr+zMirZJ/yTBi0o yqUQ==
X-Gm-Message-State: ALoCoQnCT2LoJ8Ou6QAx0muqzs1vygMnVz8sDQy6lgqANdJIW5gt8I+ytaC3sJ7t4sLz0fMdjU7j
MIME-Version: 1.0
X-Received: by 10.224.50.136 with SMTP id z8mr27981544qaf.66.1402265971057; Sun, 08 Jun 2014 15:19:31 -0700 (PDT)
Received: by 10.140.100.205 with HTTP; Sun, 8 Jun 2014 15:19:30 -0700 (PDT)
X-Originating-IP: [5.104.224.5]
In-Reply-To: <20140608153936.GF27883@mournblade.imrryr.org>
References: <CACsn0cm69oJX_Bxqerig4qBmSf1fcQWW5EG42jia3qJkTwe0Tw@mail.gmail.com> <53934B47.4090603@fifthhorseman.net> <CAFggDF0rn+xuFksKW0+xJMAxRkjb8y6=7qiEQcM200iwtzy-0Q@mail.gmail.com> <20140608101721.GA6189@roeckx.be> <CAFggDF3T33sUmEvcX643nZ6_cdXVUdmv0shrvYxn80sG3vJDRQ@mail.gmail.com> <20140608153936.GF27883@mournblade.imrryr.org>
Date: Sun, 8 Jun 2014 22:19:30 +0000
Message-ID: <CAFggDF2N6Bc5XpVZFU51XgtTM=_n1jFbGHvHK0OAwAGKp6RC5g@mail.gmail.com>
From: Jacob Appelbaum <jacob@appelbaum.net>
To: tls@ietf.org
Content-Type: text/plain; charset=UTF-8
Archived-At: http://mailarchive.ietf.org/arch/msg/tls/jCcjW0zGg91KIfcglJ5IeopMVE4
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: Sun, 08 Jun 2014 22:19:34 -0000

On 6/8/14, Viktor Dukhovni <viktor1dane@dukhovni.org> wrote:
> On Sun, Jun 08, 2014 at 03:10:46PM +0000, Jacob Appelbaum wrote:
>
>> 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.
>
> A good thing.  If the client wants a server time-stamp, it can ask
> for it via an extension.

What extension provides a time-stamp? I'd love to see a 64bit time
stamp extension but I wasn't aware of such a thing. Is there such a
thing or was that a different spec feature request?

>
>> 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.
>
> "As accurate as NTP" is a bold claim.  NTP "accuracy" (as opposed
> to precision which is a different beast entirely) comes from using
> multiple sourcs a PLL to estimate round-trip delay and smooth out
> noise, and when possible multiple sources, ...

Sure, I understand how NTP (and SNTP and TLS) works. That is something
that could be done with TLS and probably very easily with tlsdate.
Using a phase locked loop isn't something that exclusively functions
over UDP. In any case, I mean accuracy of detecting false tickers,
ensuring hostile networks aren't able to tamper with results (only
delaying or dropping them), as well as providing the precision
provided by a given NTP server. The precision is possible if the TLS
protocol is modified to provide the right data. At the moment, the
best we can get as an IETF compliant trick is 32bits (of seconds since
1970).

>
> NTP runs over UDP which is less likely to be delayed, re-transmitted, ...

I was told that part of why ChromeOS uses tlsdate is because UDP is
often delayed, dropped, and sometimes outright blocked. Also, NTP
punches a hole in a lot of firewalls that is hilariously dangerous for
some NTP implementations.

>
> Attaining NTP "accuracy" over TLS, seems rather implausible.
>

I think "over" TLS is a weird statement. Have you seen how tlsdate
works in practice?

( I often joke that tlsdate is stratum 11 but few people are fans of
Spinal Tap these days. )

All the best,
Jacob