Subject: Re: [Ntp] Circular dependencies

From: Warner Losh <[email-masked]>
Date: Sat, 16 Jan 2021 21:11:51 -0700

On Sat, Jan 16, 2021, 7:57 PM Seaman, Robert Lewis - (rseaman) <
[email-masked]> wrote:

> Hi Warner,
>
>
>
>    - Sure makes cold spares hard to implement.
>
>
>
> You’ve often made this point. Aren’t there other services that provide
> similar challenges? Starting with DNS for that matter. Some engineering
> requirements are indeed hard to implement. Coherent precise timekeeping may
> simply be one of those.
>

Yes. There are many challenges. Making precise time a requirement for DNS
in order to get the time is not a circular dependency that should be
undertaken lightly. At least with a GPS receiver you'll know the time
within a minute or two for the rest of this century even without the
almanac. Absent a GPS receiver, it can be hard to know time well enough to
trust for all things that follow. If you can control time, and time is the
basis of trust... look out.

I am just saying that the quick hacks that were suggested won't work. Any
extended downtime now needs a trusted way to bootstrap even out of date
systems that have been off and missed important updates and revocations.
Any design under consideration should use that test case to proof the
design. I'd like it to be considered and have a protocol that's proven
secure rather than everyone rolling their own. We shouldn't wave our hands
and say it is hard, but smart people will figure it out. Any proposed
system has to cope, or it simply won't work when deployed.

Things have to work both in the steady state case, and in the large step
case. Usually at least one of these is hard.

It trips up lots of designs which is why I bring it up in a lot of
contexts. :)

Warner

Stay safe,
> Rob

---

From: Hal Murray <[email-masked]>
Date: Sun, 17 Jan 2021 01:20:13 -0800

[email-masked] said:
> Yes. There are many challenges. Making precise time a requirement for DNS in
> order to get the time is not a circular dependency that should be undertaken
> lightly. 

Should we write up something on this area?  Is there a better group?

Is this one area or two?  Circular dependencies vs long shelf life?  Or are 
they tangled?

--------

I think a reasonable battery could drive a CMOS clock for 10 years. 

I could imagine a certificate and an IP Address good for 10 years.  Maybe 3 of 
them so you can survive if one breaks or out vote the bad guy if one of the 
root certificates leaks.

-- 
These are my opinions.  I hate spam.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 17 Jan 2021 21:10:38 +1100

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. 

-- 
Mark Andrews

> On 17 Jan 2021, at 20:20, Hal Murray <[email-masked]> wrote:
> 
> 
> [email-masked] said:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Hal Murray <[email-masked]>
Date: Sun, 17 Jan 2021 03:24:40 -0800

[email-masked] 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.

---

From: Mark Andrews <[email-masked]>
Date: Sun, 17 Jan 2021 23:22:28 +1100

The initial address queries by ntpdate/ntpd/etc at boot time can be done with CD=1  (checking disabled).

For real long term shelf storage the trust anchors for the root will need to be updated. 

-- 
Mark Andrews

> On 17 Jan 2021, at 22:24, Hal Murray <[email-masked]> wrote:
> 
> 
> [email-masked] said:

---

From: Mark Andrews <[email-masked]>
Date: Sun, 17 Jan 2021 23:30:17 +1100

One can also do DO=1 as well and ignore inception dates when validating in the app so that records signed after the last file system date are not rejected. 

-- 
Mark Andrews

> On 17 Jan 2021, at 23:22, Mark Andrews <[email-masked]> wrote:
>