Re: [Ntp] Circular dependencies

Hal Murray <hmurray@megapathdsl.net> Thu, 12 November 2020 00:02 UTC

Return-Path: <hmurray@megapathdsl.net>
X-Original-To: ntp@ietfa.amsl.com
Delivered-To: ntp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3CFA23A121F for <ntp@ietfa.amsl.com>; Wed, 11 Nov 2020 16:02:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.035
X-Spam-Level: *
X-Spam-Status: No, score=1.035 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=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 b8e2xnA8Pna6 for <ntp@ietfa.amsl.com>; Wed, 11 Nov 2020 16:02:24 -0800 (PST)
Received: from ip-64-139-1-69.sjc.megapath.net (ip-64-139-1-69.sjc.megapath.net [64.139.1.69]) by ietfa.amsl.com (Postfix) with ESMTP id 68CDA3A121A for <ntp@ietf.org>; Wed, 11 Nov 2020 16:02:22 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 85F5040605C; Wed, 11 Nov 2020 16:02:17 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Watson Ladd <watsonbladd@gmail.com>
cc: NTP WG <ntp@ietf.org>, hmurray@megapathdsl.net
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Watson Ladd <watsonbladd@gmail.com> of "Wed, 11 Nov 2020 09:21:45 PST." <CACsn0c=Xu31KyHu8+uq+fKBMVRt+YaJGZCfSn2ph1WXfm2atHw@mail.gmail.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Wed, 11 Nov 2020 16:02:17 -0800
Message-Id: <20201112000217.85F5040605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/60HMbf-AQRpPnvresXxjwm5rVPY>
Subject: Re: [Ntp] Circular dependencies
X-BeenThere: ntp@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ntp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ntp>, <mailto:ntp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ntp/>
List-Post: <mailto:ntp@ietf.org>
List-Help: <mailto:ntp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ntp>, <mailto:ntp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 12 Nov 2020 00:02:25 -0000

watsonbladd@gmail.com said:
> This is probably a bigger issue with NTS, as certs with IP addresses are
> harder to get. Roughtime can use its own keys, but does still rely on the DNS
> often, so it won't necessarily be a solution. Any ideas?

I think a document collecting ideas would be great.  We can turn it into an 
RFC if/when things stabilize.


I think there are 3 main cases to consider;

1) Typical PC/Server with a CMOS/TOY battery backed clock.
  During booting, the system reads the time from the clock and uses that to 
set the system time.  After that, everything just works.
  (This degenerates to case 2 if/when that clock is broken/cleared.)

2) Systems like the Raspberry Pi that have a real file system but no battery 
backed clock.  We can store the time in the file system.  This works as long 
as the systems are powered up often enough to keep the time in the file system 
close enough.

3) Systems that sit on the shelf for a long time (years).  In the old days, 
this was common in the telcom industry.  I expect it still is, but I don't 
have any solid data.  The useful lifetime of electronics is getting shorter.  
Even if the hardware doesn't die, the protocols will get updated.

The problem is that the root certificates distributed via typical distros will 
expire.  Vendors can bypass by setting up their own special long-life 
certificate chains.

---------

How close does the clock have to be for DNSSEC?  Certificates?

Are there other time-checks potentially in the chain?

Maybe a 4th case is a system being restored from backup.  Does that put a time 
limit on the useful life of backup tapes if they will be used for a total 
system restore?

--------

We can bypass the DNSSEC issues with a local DNS cache.  That will work with 
certificates that don't work with IP Addresses.  Maybe we should think of it 
as reverse DNS.  The IP Address is used to contact the server.  The name is 
what we use for certificate checking.  That depends on the IP Addresses being 
stable for longer than the system gets updated.

As Tony Finch pointed out, one of the tools we have is to setup systems with 
stable IP Addresses and long lifetime certificates.



-- 
These are my opinions.  I hate spam.