Subject: [Ntp] Circular dependencies

From: Watson Ladd <[email-masked]>
Date: Wed, 11 Nov 2020 09:21:45 -0800

Dear NTP WG,

I just realized there is a mailing list bug report that's a lot more
interesting than it seems. They have a DNSSEC validating resolver and
were using an NTP daemon to set the clock (and the RTC was busted) But
the time is needed to verify liveness of the signatures for DNSSEC to
validate, and without the names don't resolve, including the NTP
server names.

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?

Sincerely,
Watson Ladd

---

From: Tony Finch <[email-masked]>
Date: Wed, 11 Nov 2020 22:20:12 +0000

> validate, and without the names don't resolve, including the NTP

Ugh yes this has been a problem forever :-( but not a big enough problem
in practise for anyone to seriously tackle it. As if no-one cares about
making DNSSEC validation Just Work on a Raspberry Pi...

> on the DNS often, so it won't necessarily be a solution. Any ideas?

I'm eagerly looking forward to RFC 8738 ACME-IP support
https://letsencrypt.org/upcoming-features/

My fantasy solution for this bootstrapping problem is mostly about getting
an up-to-date DNSSEC trust anchor, but also the time, on a device that was
switched off while a rollover happened. When the device boots and finds
nothing works, it contacts a bunch of witnesses for which it has
preconfigured public keys and IP addresses that are expected to be stable
for the long term. It gets the current trust anchors and time from each
witness: no single witness is trusted, a large enough quorum of them have
to agree for the device to be able to recover. We assume the witnesses are
sufficiently independent that a quorum is more trustworthy than a single
trusted third party. We hope that there are enough witnesses that even
after a long time enough witnesses are stll working so an old device can
contact a quorum.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Fitzroy, Sole, Lundy, Fastnet, Irish Sea: South, veering west at times, 6 to
gale 8, occasionally severe gale 9 at first in Lundy and Irish Sea. Rough or
very rough, occasionally moderate in Irish Sea. Occasional rain. Moderate or
poor.

---

From: Daniel Franke <[email-masked]>
Date: Wed, 11 Nov 2020 17:42:37 -0500

Is there something wrong with "don't do that" as a solution? Nothing
in NTS relies on or benefits from DNSSEC, so there's no reason to
validate it. If the system resolver validates automatically and
there's no way for an application to ask it not to, then the system
resolver is (temporarily) broken and will need to be bypassed.

On Wed, Nov 11, 2020 at 1:04 PM Watson Ladd <[email-masked]> wrote:
> _______________________________________________
> ntp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ntp

---

From: Mark Andrews <[email-masked]>
Date: Thu, 12 Nov 2020 10:01:36 +1100

> On 12 Nov 2020, at 04:21, Watson Ladd <[email-masked]> wrote:
> 
> Dear NTP WG,
> 

If you have no idea of the current time just verify the signatures
ignoring the time stamps.  That is significantly better than no
verification at all.  The timestamps are there to prevent replay
attacks.  Just ask for the records and signatures (DO=1) and do your
own DNSSEC validation.  There are libraries out there that can do this
for you.

Back when I was using a machine w/o a real time clock and just power
line frequency to maintain time we touched a file in the root directory
every minute so that when the machine rebooted it would not be too far
off current time.

DNSSEC just needs to know the rough time.  Implementations already build
slack into the inception timestamp.  We all know there is clock skew in
the real world.  BIND sets it to a hour in the past by default when
generating signatures.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Hal Murray <[email-masked]>
Date: Wed, 11 Nov 2020 16:02:17 -0800

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

---

From: Danny Mayer <[email-masked]>
Date: Wed, 11 Nov 2020 19:31:22 -0500

> on the DNS often, so it won't necessarily be a solution. Any ideas?

This is not new and has been an issue for years. This is the reason why 
Autokey was developed which avoided the certificate issues with 
timestamps. This is unrelated to the problems with the Autokey protocol. 
The second part of this is if you look up IP addresses in NTP and those 
are DNSSEC protected then DNSSEC assumes that they are using accurate 
time when checking the certificates. There's no easy solution.

Danny

---

From: "Ulrich Windl" <[email-masked]>
Date: Thu, 12 Nov 2020 08:31:18 +0100

>>> Watson Ladd <[email-masked]> schrieb am 11.11.2020 um 18:21 in Nachricht
> on the DNS often, so it won't necessarily be a solution. Any ideas?

Hi!

We have similar problems with network/LDAP/user resolution, and I wondered what the "best" solution would be. When eventually deciding it would be best to have local copies of the LDAP users involved, I noticed that the tools (useradd, usermod) would not allow to create identical local users if a user with the same name exists in LDAP...

I guess  the situation should be better with the host name scenario, but unlike (system) users, DNS records change more frequently. Maybe some type of local cache ("boot persistant") would be best.

Interestingly autokey had the same problem: If the system has no time, it cannot get the time via autokey...

Regards,
Ulrich