An effort to secure the Network Time Protocol | Hacker News Reader

An effort to secure the Network Time Protocol

lwn.net

14 pointsvoxadam7 comments

Building on these ideas for replacing DNS and PKI from the other day, https://news.ycombinator.com/item?id=47212280 ; why not NTP too?

From "Decentralized DNS/PKI Enhances NTP Security" https://gemini.google.com/share/686f916c97cb :

> Securing NTP at scale requires moving away from fragile, centralized, trustful X.509 infrastructure. By assigning Decentralized Identifiers (like did:tdw or SSH-key DIDs) to individual time servers and managing their state with Key Event Receipt Infrastructure (KERI), we can completely bypass the TLS chicken-and-egg problem where a client needs the correct time to validate a server's certificate.

> To future-proof such a protocol, we can replace heavy certificate chains with stateless hash-based signatures (SPHINCS+, XMSS^MT) paired with lightweight zkSNARKs. If a node is compromised, its identity can be instantly revoked and globally broadcast via Merkle Tree Certificates and DID micro-ledgers, entirely removing DNS from the security dependency chain.

> Despite NTS becoming an IETF standard in 2020, uptake has been slow. There's been some success: Canonical, which maintains its own time servers, switched to NTS in 25.10. But the NTP reference implementation, ntpd, does not support NTS. A number of clients, such as NTPsec, chrony, and ntpd-rs, do support NTS. They are not, however, widely adopted.

> [...]

> To help spur wider adoption of NTS on Linux distributions, other Trifecta staff are also working on a patch for systemd-timesyncd.

"NTS support for systemd-timesyncd" https://github.com/systemd/systemd/pull/39010

"RFC 8915: Network Time Security for the Network Time Protocol" (2020) https://www.rfc-editor.org/rfc/rfc8915.html

Could the reason why uptake has been slow be because for about 99.9% of the world it doesn't matter if NTP is "secure" or not? There are all sorts of theoretical attacks possible, and some high-profile ones on time-based systems (that didn't involve NTP) have been done in the past, but when was the last time there was an above-the-fold news story about an NTP-based attack?

So in exchange for replacing a protocol that involves a single UDP packet back and forth and that you can implement in a few dozen lines of code on any type of device, you have to use a full TLS with PKI stack and certificates and revocation and all manner of other insanity in exchange for a perceived problem that no attacker has figured out what to do with in its forty-year history.

Heck, if you want a "secure time source" (for whatever definition of "secure" you're after) and you're going to go with the bloat and complexity of TLS and everything else, connect to www.google.com and read the value out of the HTTP Date header, that's supported right now and accessible over the public Internet from almost everywhere. And if you're on the non-public Internet, why are you worried about NTP attacks?

Except for extremely cheap embedded computers, which save a few cents by not including a battery and a quartz resonator or oscillator for a real-time clock (as a timer suitable to be used as a RTC exists even in the cheapest microcontrollers), NTP is not a major security risk, because when used in the right way it should be used just to compensate the drift of the internal RTC, which should be trusted more than NTP (for the coarse time value).

Any unexplainable discrepancy between the internal RTC and what NTP reports should be interpreted as a possible spoofing of the NTP packets and such suspect values should not be used to update the internal clock. If the accumulated adjustments of the internal clock caused by NTP exceed a few seconds per day, the sysadmin must be alerted, as something like this can happen only when either the hardware is defective or something is wrong with NTP.

Unfortunately, there are many bad implementations that follow blindly what NTP says, without checking the timestamps for plausibility. Most better implementations are still not optimal, because they just limit the time steps of the internal clock to some value e.g. to 1 second, instead of recognizing outliers in the NTP timestamps and ignoring them.

That's a valid defence, and certainly protecting against the clock being moved too far too fast is a no-brainer, but you also need to threat-model the attack: what are the chances of an real attacker (not a theoretical weakness) carrying out an NTP-based attack and what would they gain from it? For example an attacker who has control over your local network and can spoof NTP on it, which means it's probably already game over before you even start, can move the clock on something around and reuse an expired certificate if they've compromised the device and captured its private key... you can probably dream up some sort of scenario where this might be an issue and where all the other things they can do with that level of compromise of the system won't be easier but it's so far down on the list of other things that attackers could do that it doesn't even rate.

And for the few places where clock distribution is critical, e.g. when you need to use IEEE 1588 PTP (Precision Time Protocol) you're typically running over tightly-controlled private links/networks or protocols (IEC 61850, 62439) and/or using GPS or rubidium clocks as your time source, not NTP. Or you sync using nonces, not time. Or whatever. It's just really hard to come up with a real-world scenario where this is a significant threat, and moreso one where the answer would be to run NTP over TLS rather than just using some better mechanism for the job.

> NTP is not a major security risk

NTP failure and clock drift on a home router with DNS-over-HTTPS results in total denial of (DNS-based) internet access due to DoH certificate validity, for example.

NTP failure can result in misdated log messages.

NTP control hijacking can result in misdated log messages.

Reply on news.ycombinator.com