On 1/19/22 3:13 PM, Bernhard Schmidt wrote:
I agree we should have a look at this (either ntpsec or chrony, both do NTS), but I think this should be done completely independently of the ntp.org->ntpsec migration.
+1 that promoting NTS is orthogonal.If the bigger problems below are solved, it's also theoretically possible to add NTS support to systemd-timesyncd.
- AFAIK there is no pool.ntp.org (or similar) service only containing NTS enabled timesources yet.
This is the most serious problem. As the world stands right now, we'd have to do something like use CloudFlare's NTS service (and only them).
I don't know how it would work either, since you need to verify the peer with a standard X.509 certificate and you don't know the expected CN from a DNS RR
NTS does referrals, so it is theoretically possible for the NTS server to hand you off to a pool of NTP servers, with which it is coordinating keys. AFAIK, nobody has implemented this yet, outside of maybe CloudFlare's internal thing (but I don't recall off the top of my head).
- Since NTS leverages X.509, how does it work with a broken clock on boot that is ticking outside of the certificate validity period?
This is a concern too. I did some brainstorming about this on the NTPsec list a couple years ago, but neither I nor anybody else has implemented this (nor do I have plans to do so myself):
https://lists.ntpsec.org/pipermail/devel/2019-February/007576.html -- Richard
Attachment:
OpenPGP_signature
Description: OpenPGP digital signature