For servers it's definitely harder, although definitely not only state-level, but another big issue could be client-side. NTP servers can be set by DHCP, so the admin of any network you connect to could exploit such a bug against you. And once you have code execution on a desktop OS, all bets are off, even if you're not under the primary UID.
It's not the most important threat vector, but it also doesn't seem as difficult as some of the other system services to rewrite, so I'd say it was a good first step for the memory-safe-everything project.
(But regardless: “the transport layer is secure” is not a good reason to leave memory unsafe code on the network boundary. Conventional wisdom in these settings is to do the “defense in depth” thing and assume that transport security can be circumvented.)
There aren’t many public NTS servers: https://netfuture.ch/public-nts-server-list/ and https://github.com/jauderho/nts-servers have some listed.
> Yes it does. ntp uses TLS to communicate with it's well known locations.
My knee-jerk reaction is that TLS is not authentication. After skimming through the relevant spec [0], it is interesting how NTP uses TLS.
[NTS-KE] uses TLS to establish keys, to provide the client with an initial supply of cookies, and to negotiate some additional protocol options. After this, the TLS channel is closed with no per-client state remaining on the server side. [0]
ntpd can (and should) run as a user
> talks to the network
Makes outbound requests to the network. For it to be compromised, the network itself or a downstream server needs to be compromised. That's very different from something like hosting an http server.
> doesn't usually authenticate its traffic
Yes it does. ntp uses TLS to communicate with it's well known locations.
> uses a bespoke binary packet format
Not great but also see above where it's talking to well known locations authenticated and running as a user.
It's a service that to be compromised requires state level interference.