Re: [TLS] Server time
Tom Ritter <tom@ritter.vg> Mon, 06 April 2015 11:35 UTC
Return-Path: <tom@ritter.vg>
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 92BA41A87AA for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 04:35:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.379
X-Spam-Level:
X-Spam-Status: No, score=-1.379 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, SPF_PASS=-0.001] 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 kXOpm2d46KGg for <tls@ietfa.amsl.com>; Mon, 6 Apr 2015 04:35:14 -0700 (PDT)
Received: from mail-ig0-x22e.google.com (mail-ig0-x22e.google.com [IPv6:2607:f8b0:4001:c05::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 906381A87A6 for <tls@ietf.org>; Mon, 6 Apr 2015 04:35:14 -0700 (PDT)
Received: by ignm3 with SMTP id m3so17779515ign.0 for <tls@ietf.org>; Mon, 06 Apr 2015 04:35:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ritter.vg; s=vg; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=1hIm6BH/dqmd8SGC930EPG3WLPfzDadAETPUczEz9xs=; b=ov10zjc4q/qxrPY7vPVqUeOZilmBmv3zzYaDFMD8DBXlNyi15HVcSlF+oD4oBtWPNC OL4MhNvGRPyrijVuydLEQylZBcTIjZfc43ZCKjdw2sBHb9kcFkDXllAIf2Huxb6b3khn CBC+DKbRYCPMqrbpA8Icxu3avmhlleNlww0uU=
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:from:date :message-id:subject:to:cc:content-type; bh=1hIm6BH/dqmd8SGC930EPG3WLPfzDadAETPUczEz9xs=; b=JczEKBfP/CuXi8BQbioQP+2mmTqeVMeEtDXgW5gepjYgpjovkic79D/2hjqbmuXmE7 Sqt3RBwNYX3qRv7T1GdJe+ok6U06N5zr3R8udL7gI+qNzDAExMKxewKAFjzAwKoYTUTr Uvd3p1mqoiOGtjGnHPaBxHzszbOjYqWe7FxEJ9r+uZkqGQvLInmBrSdAG5mDp80Bna0E QOsrnZk6rgMR9YWbkVTZZxdC001YV71Aho49O0ZTYvAxnGi+v7yoX4x2oSskQHqs43U4 oSoITBmIfabrkJKc4nRCjUqwWmmYDvj55iydrZnK91Wf+icFRlvVtwHzHa0OD2waC6Qc W+Bg==
X-Gm-Message-State: ALoCoQmxHK/gPy7D6+qafU5+WYD9K7vkgecH40ptK0NP70XQer7ZjRebXtRdJdckgJ/5x3XP/+aH
X-Received: by 10.107.156.19 with SMTP id f19mr21716275ioe.45.1428320113964; Mon, 06 Apr 2015 04:35:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.107.166.84 with HTTP; Mon, 6 Apr 2015 04:34:53 -0700 (PDT)
In-Reply-To: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz>
References: <9A043F3CF02CD34C8E74AC1594475C73AAFDB939@uxcn10-tdc05.UoA.auckland.ac.nz>
From: Tom Ritter <tom@ritter.vg>
Date: Mon, 06 Apr 2015 06:34:53 -0500
Message-ID: <CA+cU71mRLpL71hTatp2jQjt8SCkM1_e3dAAun9TAGyTshA3_4A@mail.gmail.com>
To: Peter Gutmann <pgut001@cs.auckland.ac.nz>
Content-Type: text/plain; charset="ISO-8859-1"
Archived-At: <http://mailarchive.ietf.org/arch/msg/tls/ORzzpGUlJIaqcj9YEp9Lwxmcy-M>
Cc: "<tls@ietf.org>" <tls@ietf.org>
Subject: Re: [TLS] Server time
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, 06 Apr 2015 11:35:15 -0000
On 6 April 2015 at 06:15, Peter Gutmann <pgut001@cs.auckland.ac.nz> wrote: >>The ability of a client to sanity check or sync its time seems like something >>worth having, especially for only a 4 byte cost. > > Given that there's already a globally-deployed dedicated infrastructure that > requires nothing more complicated than sending a single UDP packet to port 123 > and checking the response, turning your TLS server into a sort of proxy time > server that may or may not have the correct time in the first place seems like > a bad idea. Is it better or worse than relying on a completely unauthenticated protocol to get the time? AGL commented earlier on this topic that ChromeOS uses (a fork of?) tlsdate to set the time securely, and that Google will likely keep some (all?) servers responding with a valid time to support that use case. I don't know what other users of tlsdate (Whonix, etc) point to. I think we can do away with server time in TLS 1.3, and the future solution is TLS 1.2 to a known-good server (or HTTPS for the Date Header) for rough time accuracy and NTP for correcting the skew. -tom
- [TLS] Server time Dave Garrett
- Re: [TLS] Server time Erik Nygren
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Dave Garrett
- Re: [TLS] Server time Dave Garrett
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Hauke Mehrtens
- Re: [TLS] Server time Brian Smith
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Eric Rescorla
- Re: [TLS] Server time Dave Garrett
- Re: [TLS] Server time Peter Gutmann
- Re: [TLS] Server time Tom Ritter
- Re: [TLS] Server time Kurt Roeckx
- Re: [TLS] Server time Peter Gutmann
- Re: [TLS] Server time Martin Thomson
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Adam Caudill
- Re: [TLS] Server time Jeffrey Walton
- Re: [TLS] Server time Ben Laurie
- Re: [TLS] Server time Florian Weimer
- Re: [TLS] Server time Peter Gutmann
- Re: [TLS] Server time Florian Weimer
- Re: [TLS] Server time Kurt Roeckx
- Re: [TLS] Server time Florian Weimer
- Re: [TLS] Server time Kurt Roeckx
- Re: [TLS] Server time Jeffrey Walton