Huston: Revisiting time [LWN.net]

Geoff Huston looks at the network time protocol, and efforts to secure it, in detail.

NTP operates in the clear, and it is often the case that the servers used by a client are not local. This provides an opportunity for an adversary to disrupt an NTP session, by masquerading as a NTP server, or altering NTP payloads in an effort to disrupt a client's time-of-day clock. Many application-level protocols are time sensitive, including TLS, HTTPS, DNSSEC and NFS. Most Cloud applications rely on a coordinated time to determine the most recent version of a data object. Disrupting time can cause significant chaos in distributed network environments.
While it can be relatively straightforward to secure a TCP-based protocol by adding an initial TLS handshake and operating a TLS shim between TCP and the application traffic, it's not so straightforward to use TLS in place of a UDP-based protocol for NTP. TLS can add significant jitter to the packet exchange. Where the privacy of the UDP payload is essential, then DTLS might conceivably be considered, but in the case of NTP the privacy of the timestamps is not essential, but the veracity and authenticity of the server is important.
NTS, a secured version of NTP, is designed to address this requirement relating to the veracity and authenticity of packets passed from a NTS server to an NTS client. The protocol adds a NTS Key Establishment protocol (NTS-KE) in additional to a conventional NTPv4 UDP packet exchange (RFC 8915).

No protection from delay attacks

Posted Mar 8, 2026 20:45 UTC (Sun) by DemiMarie (subscriber, #164188) [Link] (3 responses)

NTS does not (and cannot) protect against delay attacks, where an attacker introduces asymmetrical network latency. The only way to do this is to know a lower bound on the latency to the server. My understanding is that an accurate lower bound is only possible for free-space radio or optical transmission, where it can be calculated by dividing the distance by the speed of light.

No protection from delay attacks

Posted Mar 9, 2026 15:17 UTC (Mon) by farnz (subscriber, #17727) [Link] (2 responses)

You can put an accurate lower bound on cable transmission, too, by accounting for the velocity factor of signals in the cable.

Just as 300 metres per microsecond is a good approximation in free space, 200 metres per microsecond is a good approximation in common cable types (OS1/OS2 fibre, Cat5e or 6A twisted pair).

The hard part (in all cases) is working out the lower bounds added by software queues, NIC queues, DMA, serialization/deserialization, any standing queues in the network, FDB lookups (whether by IP or by MAC address) etc. Hardware timestamping can help, by timestamping at serialization and deserialization time, but as soon as you leave a tightly controlled network, it becomes an intractable problem (you may know that your switch has the same 20 µs minimum switching delay as mine, but you don't know what the queue lengths I permit are).

No protection from delay attacks

Posted Mar 10, 2026 11:37 UTC (Tue) by hmh (subscriber, #3838) [Link] (1 responses)

The moment you are paying attention to wired local network delays, you have long abandoned the problem domain of NTP and you're now well into the problem domain of PTP.

PTP has provisions for network delay and packet forwarding delay, and targets accuracies on the sub-millisecond range. It is also *very* different from NTP.

Note that it *is* possible to have 1ms-accurate NTP, with several restrictions. I have it on my workstation at work, but IME it is not something you can expect to get out of a NTP client syncing to servers over commercial broadband Internet connections, or when WiFi is involved, etc.

No protection from delay attacks

Posted Mar 10, 2026 12:41 UTC (Tue) by daroc (editor, #160859) [Link]

Some profiles of PTP can get synchronization down to the tens-of-nanoseconds, although that does require special hardware support! Across a local, wired, Ethernet network with bridge clocks instead of transparent clocks and hop-by-hop delay measurement (PDelay), you can get things into the 40-80ns range in lab conditions.

I used to work at the University of New Hampshire InterOperability Laboratory in the Time Sensitive Networking group where, among other things, we tested PTP devices for conformance with the standard. It was really fun working with those kinds of incredibly precise clocks. I fondly remember pulling coaxial cable for our GNSS antenna so that we could finally have a proper atomic clock to test against.

TLS without time?

Posted Mar 10, 2026 8:18 UTC (Tue) by taladar (subscriber, #68407) [Link] (2 responses)

Is TLS really that straightforward if you can't rely on having accurate time?

TLS without time?

Posted Mar 10, 2026 10:10 UTC (Tue) by Fowl (subscriber, #65667) [Link]

Conceptually for the vast majority of systems I’d imagine “anything in the future relative to the last trust/revocation store update” would narrow any window for compromise to something acceptable, and better than just accepting whatever the network provides blindly.

Whether popular libraries make implementing this easy and determining the host name to validate against is probably the hard part.

TLS without time?

Posted Mar 10, 2026 12:33 UTC (Tue) by farnz (subscriber, #17727) [Link]

Yes - most TLS libraries have some equivalent of OpenSSL's X509_V_FLAG_NO_CHECK_TIME, and you can thus do TLS without expiry or not-before times, at a reduction in security due to no accurate time.

It's possible to be more sophisticated, and say that time starts out at boot at the most recent recorded accurate time (build time for this code, for example), and is advanced if you see evidence that you're in the past (e.g. you read a timestamp recorded when you last had accurate time from persistent storage, or you can't connect to NTS-KE because of a notBefore time in the certificate chain that's in the future). But that's not necessary complexity - that's a consequence of wanting more security than TLS without any time checks provides.

Note that the idea of "wanting more security" is critical here - TLS with certificate chain checking but no time checks at least proves that an attacker has obtained a certificate from an authority you trust at some point in time, on top of being able to MitM communications between you and the NTS-KE server. Time checks establish bounds on "some point in time", but if those risks are critical in your application, you need some way to ensure that you always have accurate enough time to do TLS with time checking (noting that you may not need great accuracy for this - being right to within 24 hours is probably enough).

Roughtime?

Posted Mar 10, 2026 10:12 UTC (Tue) by Fowl (subscriber, #65667) [Link] (2 responses)

I wonder how how roughtime (mentioned in an LWN comment - https://lwn.net/Articles/702167/) is going. Seems like getting within 10second or so would be useful for many systems, and even just for bootstrapping for even more.

Roughtime?

Posted Mar 10, 2026 11:50 UTC (Tue) by hmh (subscriber, #3838) [Link] (1 responses)

HTP[1] over HTTP and HTTPS [with timestamp checking disabled] is *really* common during bootstrap on RTC-less devices. And you *could* do multi-server, quorum-based HTP over HTTPS (so, reasonably well protected against forgery) if you really wanted to: just take the median of several queries to a diverse set of servers. It is also extremely CDN friendly ;-)

I guess the simplicity of using HTS was deemed good enough by the majority, so Roughtime is not very widely known or deployed. But I'd love to be told otherwise.

[1] HTTP time "protocol": do a HTTP(s) GET request to known/trusted servers and parse the returned Date header.

Roughtime?

Posted Mar 10, 2026 12:31 UTC (Tue) by hmh (subscriber, #3838) [Link]

Hmm, I did some searching and it appears Roughtime is moving forward[1], which is good. Looks like it might be well deployed in Cloudflare and a few others...

[1]https://www.ietf.org/archive/id/draft-ietf-ntp-roughtime-...

Huston: Revisiting time

NTP over QUIC

No protection from delay attacks

No protection from delay attacks

No protection from delay attacks

No protection from delay attacks

TLS without time?

TLS without time?

TLS without time?

Roughtime?

Roughtime?

Roughtime?