IETF Logo Mail Archive

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

v2.23.0 | Report a Bug | By Email