Re: Predictable Internet Time

Phillip Hallam-Baker <phill@hallambaker.com> Tue, 03 January 2017 16:33 UTC

Return-Path: <hallam@gmail.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5FFA41296B7 for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 08:33:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 tu5Wdv7-1rkx for <ietf@ietfa.amsl.com>; Tue, 3 Jan 2017 08:33:17 -0800 (PST)
Received: from mail-wj0-x22f.google.com (mail-wj0-x22f.google.com [IPv6:2a00:1450:400c:c01::22f]) (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 2597312966C for <ietf@ietf.org>; Tue, 3 Jan 2017 08:33:17 -0800 (PST)
Received: by mail-wj0-x22f.google.com with SMTP id v7so449254003wjy.2 for <ietf@ietf.org>; Tue, 03 Jan 2017 08:33:17 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=t0nquamtrQJ3usKfUvgX2V6ewMlFoZnNCAAEtPWPPgg=; b=qPdmF7UTKjKreQmH6Moi5k4Prl/XbER+PrBnVKQC0dBnGVXcZnoUm1f31kaVoc9JNu cbncp5B5r7c6QB9a+g4WH0A7ien2QVah7/ZaY20h52k7h8WodG7vxDtY/wk0RuENcpLX 13Yo7KBVLVAv2yOzbmHB7WFvG/h4PfFxBQcX9UFk/Hcw/RicGu8dtiNyHxjqDXME3jo2 iA3bpvnnHnczadUxuC3yYHO769ttKfqNrrPiNil7B/5H/qWPUiqEWOmKxomYUKquNYtW aZ7WvLYDCU6XcSQNUGPgjzpPakVJXkTEZRwZN4/gqW37LlV5Z2bFHeTPPxi6e53l9O/U RO5g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=t0nquamtrQJ3usKfUvgX2V6ewMlFoZnNCAAEtPWPPgg=; b=N+oDwB3P51jcpozT8lp+TotblckGThofGGe7XGF3gpD6M2dQvpIrfLG56jLFBei7D7 LWcASzvgmwWH3Cp5DLQz3PBuD/WXcZ4klUKsa9yWTRT8eU1jhd6CNjsWLfSv1nddSJff cZyNGYlye8ieirH+d/l7cHqfBhATnH0jQT4ohGKTL9f6hqVxSMbJVlz4hWbYn4DxyJ9m T1a4rIB6oRZOpRzhhiUcasUiEA/G6bpQM/cewHoPzWz1YtU5OsvOug2bHDkhSr3py0qz YPwT09l5dhqB/7+jWqOpPakuwXwXsFNaQTyxg1P92163+o+vkXWhhi2pfdiUS0fHr7sr TuUg==
X-Gm-Message-State: AIkVDXL1VFBLh5pRtdcntbIeS2TBZDOIttM9+7KNeZzXNA/++hg+2A14qBh0dvt8BFdlWrwY42jNrnglEk8Rpg==
X-Received: by 10.194.2.9 with SMTP id 9mr52772234wjq.6.1483461195532; Tue, 03 Jan 2017 08:33:15 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.83.101 with HTTP; Tue, 3 Jan 2017 08:33:14 -0800 (PST)
In-Reply-To: <B990A5A4-D62B-4E10-9FF7-7BA4377C0958@frobbit.se>
References: <CAMm+LwgfQJ8aG5wB=d3fRbbeje3J9o7Z4_DCuP8DL88ouDeKzw@mail.gmail.com> <504e2cea0d1668c31486b05fec0a967a4446aefe@webmail.weijax.net> <CAMm+Lwi_jU6gjdtdM6a2n_9_89tUvWBNXxnMtSjTEA++h1D4Ew@mail.gmail.com> <e0a43370-751f-808c-3719-9716f9cd57d1@isi.edu> <B990A5A4-D62B-4E10-9FF7-7BA4377C0958@frobbit.se>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Tue, 3 Jan 2017 11:33:14 -0500
X-Google-Sender-Auth: c9owxGZicVRsEg9iDfc4AITK_7k
Message-ID: <CAMm+Lwgh8TKZ21s2KLv1ONitjnDg--3aEE9uJh5Fnba=wd8nFA@mail.gmail.com>
Subject: Re: Predictable Internet Time
To: =?UTF-8?B?UGF0cmlrIEbDpGx0c3Ryw7Zt?= <paf@frobbit.se>
Content-Type: multipart/alternative; boundary=047d7b3a87889911be0545333966
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/d-Z_Wo1vD_6DjmW39UfGsFKIM-E>
Cc: IETF Discussion Mailing List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 03 Jan 2017 16:33:19 -0000

I agree with most of what Patrik is saying. With one major difference, The
deviations file needs to be signed because it is a security issue.

And once you sign the file, the next question is... by whom.

I would much rather eliminate unnecessary trust dependencies than
perpetuate them.


Use of time zones at the protocol level is generally an option. XML Schema
uses UTC. Most implementations of IETF protocols use either UTC or UTC with
a numeric offset.

So it is an issue but mostly a UI issue rather than a security issue. It is
still necessary to have a signed table of the expected changes though
because agreeing to meet once a week at 10:00 London Time is not the same
as agreeing to meet once a week at 10:00 UTC+0 due to the fact that there
will be summer time half the year. A person in New York may attend meetings
in London and so the adjustments need to be known globally.

Contrary to what the calendar people tell me, these issues are not
'difficult'. What is difficult is using programs that make unfounded
assumptions about the adjustments to apply rather than letting these be set
by the user.



On Tue, Jan 3, 2017 at 1:29 AM, Patrik Fältström <paf@frobbit.se>; wrote:

> There are a number of complicating factors here. One being that we have
> multiple time scales. Another being that parties do believe things are what
> they really are.
>
> The main issue with smearing is that UNIX time is really not counting
> number of seconds from the epoch, which might be what people think. If it
> was, smearing would not be a good thing as the number of seconds from the
> epoch ends up being one less due to the smear than the continuous series of
> SI-Seconds. The number of seconds is guessing that each day have the same
> number of seconds. So leap seconds are ignored.
>
> Instead the goal with the smear is only to be correct according to UTC.
>
> A correct implementation would of course be to have the number of seconds
> from Jan 1 1970 be correct, and then a correct translation to UTC. Which
> requires (both) knowledge of the number of leap seconds -- which you only
> know for each 6 month interval (sort of). So one do not know the
> translation between number of seconds since epoch and UTC if you look say 3
> years forward in time.
>
> I think personally, as long as we do have leap seconds:
>
> - we should have the leap second information available somewhere in clear
> machine readable format. Some suggestions exists, including encoding it in
> A-records in DNS ;-)
>
> - we should look at having the time since epoch really be the number of
> SI-seconds since the epoch
>
> - we should have translation between number of seconds and UTC take leap
> seconds into account
>
> - we should fix the code that do not accept 61 seconds in a minute
>
> Now, we can also say we should stop having leap seconds, but I feel that
> is a _different_ matter and different discussion. I am myself not clear
> over what is the correct thing regarding leap seconds.
>
> What I am sure of is that I think most of the problems we have is because
> of bad programming (including in old UNIX days the priorities although
> correct at the time have continued to let the time_t definition continue to
> be wrong).
>
>    Patrik
>