Re: Predictable Internet Time

Phillip Hallam-Baker <phill@hallambaker.com> Thu, 05 January 2017 16:03 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 73E0C129B5D for <ietf@ietfa.amsl.com>; Thu, 5 Jan 2017 08:03:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.597
X-Spam-Level:
X-Spam-Status: No, score=-2.597 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_LOW=-0.7, 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 DDoqBxIjswFh for <ietf@ietfa.amsl.com>; Thu, 5 Jan 2017 08:03:50 -0800 (PST)
Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 AFEC01295BC for <ietf@ietf.org>; Thu, 5 Jan 2017 08:03:49 -0800 (PST)
Received: by mail-wm0-x229.google.com with SMTP id c85so251744235wmi.1 for <ietf@ietf.org>; Thu, 05 Jan 2017 08:03:49 -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=OilDf9xH7/CRyjFjmDEL6w6FhFJOmbMi7MzHL9HEDqc=; b=a4XXGFSNdZ1YSwIv7KyQP5vZVNkjfChoAFDGeH9G0EdEBtGM+WwjHQI24lYT6ZA+tX 3N0tavuAGZ6k5q+v9kLaShBT9gMRX4rxa+74UCFNl1uIED7ysa9lIu7clgznraYrJ76b pCBZTiWW5wWHzlI3VlF0O/venWdNJx4gnIewYWD3hj8L8TKt0dp0uKOxBt6D9VDFzRuZ uYnkaKt7hInn9CGM4k7B9WcYWaAGwIM2c241iR3PfzEQAt/2Y1cTDNY8fNBlb9CjcSdE p6ydOZPxaQOP/i0jtss1gD+QYy/jCZjpIAvP1bQpvkZL3guzrZDeCRxZDDf99cM+Q0GQ Tbeg==
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=OilDf9xH7/CRyjFjmDEL6w6FhFJOmbMi7MzHL9HEDqc=; b=neHCvcXNKgJugpe2I2t4lsEJnxWhtzyrMEQaZ7kQUfCIPc8wYEg7imQGWdqq5+CZY/ IJlr8UND9OzEm/N7ccL3PSpcuR9RQdD7M3KqcLnXxJ+zTOpQuxC3PG+TrxzC3vDIKyrL s2sZIJBLhEpETeXtoJod909MrvrC4LO12uFxLu9YWEnbsFLdwOo9NmsgS8w+VTkqiAfL SePdIxJezl5AGxiS7ubqW+baJYQGMNu8x3GepVlSF3OpeUp+qRP8f9Zp+35f7ez5YoCC shOtW+D6DQfegxPQoZAo0RWMyZ5luUkCDPM5oqxxNQMRGX3MP1sIWGNmb4GDdVlTSPlt qBQQ==
X-Gm-Message-State: AIkVDXKECfjihFyvwdLQJd5NE9n1dCVHvoxohf9VjaFsLPQ/O4pPlKONbKHujBzOf2WZGwMNu9PMIggKTk7GdA==
X-Received: by 10.28.20.3 with SMTP id 3mr5841961wmu.9.1483632228126; Thu, 05 Jan 2017 08:03:48 -0800 (PST)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.194.83.101 with HTTP; Thu, 5 Jan 2017 08:03:43 -0800 (PST)
In-Reply-To: <dbeb65fb-03e2-90fb-bdaa-cb7606d50793@mnt.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> <CAMm+Lwg8UzhyqNBrsxNb_8uFLCrL-iqpjPGwfycmvPEOcuE8LA@mail.gmail.com> <9cc49e0a-1aac-67e0-f198-4e0673340394@cisco.com> <CAMm+LwjSPnimVYmF0WmKT0zNxETt53fxVM+7D+Q2Rmi7nPFsHw@mail.gmail.com> <dbeb65fb-03e2-90fb-bdaa-cb7606d50793@mnt.se>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Thu, 05 Jan 2017 11:03:43 -0500
X-Google-Sender-Auth: g7_OWI_9OdSH5ftxSKDN0PLO1Iw
Message-ID: <CAMm+Lwj3atF_pzmSbFjSE2+AjQbkaL3pEs8w0JmoYxwzovzgCw@mail.gmail.com>
Subject: Re: Predictable Internet Time
To: Leif Johansson <leifj@mnt.se>
Content-Type: multipart/alternative; boundary="001a1145aef0ef614e05455b0b25"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf/Qi5OuMREh5Dx40fQskSfNGpEZ_k>
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: Thu, 05 Jan 2017 16:03:51 -0000

On Thu, Jan 5, 2017 at 8:35 AM, Leif Johansson <leifj@mnt.se> wrote:

>
>
> > *​ The governments will do whatever their banking and broadcast sectors
> > tell them.
>
> I doubt this statement would turn out to be true (since agreements on
> standardized units of measurement is somewhat older than the interwebs
> etc) but mostly I don't see how the political mess you propose is worth
> the "win" of not having to deal with the odd leap-second now and then.
>
> I could think of tastier fish to fry - for instance a way to do secure
> time at Internet scale.
>

​That was the reason I decided to kill the unpredictable leap seconds in
the first place.

As with many Internet infrastructure improvements, secure time isn't very
interesting on its own. It is interesting but not interesting enough to get
people to deploy.

Instead, I propose a one stop shop for all trust services:

* Trusted Time
* Trusted DNS resolution
* Trusted trust broker (c.f. XKMS, SCVP, ...)

I call this a Mesh portal.

The idea being that every Internet device that a person owns can be
connected to the ​Mesh portal of their choice that will serve as a one stop
shop for all three.

Note that trusted does not mean trustworthy. I certainly want to limit the
degree of trust required to the absolute minimum.

For trusted time, I would want the Mesh portal to run a local linked notary
log (c.f. blockchain) that would prevent clock rollback.The portal would
also run a notary service allowing transactions to be protected against
rollback.

So the local notary log would operate on a time interval of a minute. Every
15 minutes or so the Mesh portal would cross notify with a random selection
from a set of peers. Every hour the peer group would cross notify with a
member of a Meta notary set.

In this way the time is bounded as follows

Accurate to 100ms or better:
    On the authority of the portal alone

Accurate to 1 minute or better:
    On authority of portal with qualified accountability to relying parties

Accurate to 15 minute or better:
    On authority of portal with unqualified accountability to peer group

Accurate to 60 minutes or better:
    With full transparency

​Changes in the definition of time are driven by two things: technology for
telling time and the use made by technology. The time zone system we use
today has its origins in railway time developed by and for the railways.​

The type of application I would see this being used for is for notarizing
digital evidence during collection.


Right now, I am still at the design stage. As I said, I don't think this
system provides sufficient value on its own but it could if combined with
other purposes such as payment transfers etc.

The main reason I want the system is actually to service a next generation
PKI designed to service client side keys.