Re: [Ntp] Circular dependencies

Hal Murray <hmurray@megapathdsl.net> Sun, 17 January 2021 11:24 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 26DA73A0FCD for <ntp@ietfa.amsl.com>; Sun, 17 Jan 2021 03:24:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.038
X-Spam-Level: *
X-Spam-Status: No, score=1.038 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_DYNAMIC_IPADDR=1.951, PDS_RDNS_DYNAMIC_FP=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RDNS_DYNAMIC=0.982, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=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 XL3W4E9c0Voh for <ntp@ietfa.amsl.com>; Sun, 17 Jan 2021 03:24:43 -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 DDC383A0FCC for <ntp@ietf.org>; Sun, 17 Jan 2021 03:24:41 -0800 (PST)
Received: from shuksan (localhost [127.0.0.1]) by ip-64-139-1-69.sjc.megapath.net (Postfix) with ESMTP id 486D740605C; Sun, 17 Jan 2021 03:24:40 -0800 (PST)
X-Mailer: exmh version 2.7.2 01/07/2005 with nmh-1.3
To: Mark Andrews <marka@isc.org>
cc: Hal Murray <hmurray@megapathdsl.net>, NTP WG <ntp@ietf.org>
From: Hal Murray <hmurray@megapathdsl.net>
In-Reply-To: Message from Mark Andrews <marka@isc.org> of "Sun, 17 Jan 2021 21:10:38 +1100." <61B0A79E-FFED-494F-B7FD-60BEF7F61B62@isc.org>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Date: Sun, 17 Jan 2021 03:24:40 -0800
Message-Id: <20210117112440.486D740605C@ip-64-139-1-69.sjc.megapath.net>
Archived-At: <https://mailarchive.ietf.org/arch/msg/ntp/R8u85kLZA8446bDkrWAkw8hNDKs>
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: Sun, 17 Jan 2021 11:24:44 -0000

marka@isc.org said:
> In practice DNS does not need precise time.  Implementations know that
> validators and signers are NOT using precise time. BIND for example signs
> records with a time stamp a hour in the past and records are supposed to be
> replaced days before they expire.

I'm thinking of a different scale on "precise", months or years rather than 
hours or days.

The usual example is a device that has been sitting on the shelf for 10 years. 
 The only time it has is when the software was built or installed, just before 
it was packaged up.

The telcom guys do that.  (Or did.)  I wouldn't be surprised by military gear 
with similar time scales.

I could easily imagine a Raspberry Pi being powered off for a whole summer.  Or a smart fridge being off for half a year if it lives at a summer home.

Anything with a file system that is operating can update the last-known-time occasionally.  That's good enough for normal certificates if "operating" means turned on once a month, maybe even once a year.

-----------

We should collect a list of files/data that need to be updated occasionally.  The obvious ones for this group are root certificates and the time-zone database if you need local time and maybe the leap-second file.

There is the whole can of worms about the software/protocols still being in use after 10 years.

-- 
These are my opinions.  I hate spam.