rlaager

ntp has been replaced by ntpsec in Debian. (I am the Debian ntpsec package maintainer.) By default, NTPsec on Debian uses the NTP Pool, so no NTS. But NTPsec does support NTS if you are running your own server and supports it opt-in on the client side.

As far as I know, the Debian “default” is systemd-timesyncd. That is what you get out of the box. (Though, honestly, I automate most of my Linux installs, so I don’t interact with a stock install very often.) AFAIK, systemd-timesyncd does not support NTS at all.

Doing NTS on a pool would be quite complicated. The easy way is to share the same key across the pool. That is obviously not workable when pool servers are run by different people. The other way would be to have an another out-of-band protocol where the pool NTP servers share their key with the centralized pool NTS-KE servers. Nobody has built that, and it’s non-trivial.

I don't know much about this situation, but from what I've read, you were clearly in the right. It doesn't matter if the feature is in optional/experimental code. If it's there and has a vulnerability, give it a CVE. The customers/users can choose how much they care about it from there.

> Honestly, anyone could have gone to a CNA and demanded a CVE and he would not have been able to stop it. That's how it works.

I recently did exactly that when a vendor refused to obtain a CVE themselves. In my case, I was doing it as part of an effort to educate the vendor on how CVEs worked.

I think you could manually substitute in the old chain—up until the point the signature expires. That would get you until the September date. I wouldn’t recommend it, but that could be useful to buy just a little more time if one was desperate.

Initially, they likely didn’t think they had a choice. The root that had cross-signed them was expiring. (And I wonder if anyone else was willing to cross-sign them.) It turns out that root expirations are handled differently (i.e. ignored) on some platforms, including the relevant old Android.