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.
- [Ntp] Circular dependencies Watson Ladd
- Re: [Ntp] Circular dependencies Tony Finch
- Re: [Ntp] Circular dependencies Daniel Franke
- Re: [Ntp] Circular dependencies Mark Andrews
- [Ntp] Fwd: Circular dependencies Mark Andrews
- Re: [Ntp] Circular dependencies Hal Murray
- Re: [Ntp] Circular dependencies Danny Mayer
- [Ntp] Antw: [EXT] Circular dependencies Ulrich Windl
- Re: [Ntp] Circular dependencies Philip Prindeville
- Re: [Ntp] Circular dependencies Warner Losh
- Re: [Ntp] Circular dependencies Warner Losh
- Re: [Ntp] Circular dependencies Hal Murray
- Re: [Ntp] Circular dependencies Mark Andrews
- Re: [Ntp] Circular dependencies Hal Murray
- Re: [Ntp] Circular dependencies Mark Andrews
- Re: [Ntp] Circular dependencies Mark Andrews