An effort to secure the Network Time Protocol [LWN.net]

February 25, 2026

This article was contributed by Joab Jackson

The Network Time Protocol (NTP) debuted in 1985; it is a universally used, open specification that is deeply important for all sorts of activities we take for granted. It also, despite a number of efforts, remains stubbornly unsecured. Ruben Nijveld presented work at FOSDEM 2026 to speed adoption of the thus-far largely ignored standard for securing NTP traffic: IETF's RFC-8915 that specifies Network Time Security (NTS) for NTP.

I was not able to attend FOSDEM this year, but I watched the video for the talk in order to put together this article.

According to Nijveld, NTP is "fundamentally a broken protocol. It is a protocol that is fundamentally insecure". His employer, the Dutch nonprofit Trifecta Tech Foundation, is testing technologies that would make it easier for pool.ntp.org, and other large-scale time servers, to adopt NTS. That work is receiving additional funding from ICANN and other interested parties, he said. The foundation's specialty is improving open-source infrastructure software, and Nijveld himself is an expert on time synchronization software, having worked on or with ntpd-rs, and Statime for the IEEE's Precision Time Protocol.

The universal need for time

NTP was originally authored by the University of Delaware's David Mills, who passed in 2024. It is now almost universally used to synchronize everything else on the Internet with the Coordinated Universal Time (UTC) by referencing time data from high-precision timekeeping devices such as atomic clocks. Those are referred to as "Stratum 0" time sources in the hierarchy of time sources.

NTP timestamps are essential for computer-related synchronization tasks such as issuing Kerberos tickets, and TOTP tokens for one-time passwords. "If your clock is off by a minute, good luck getting a proper TOTP token, because they are only valid for a minute, generally." Database synchronization, distributed-systems logging, and in fact almost all of distributed computing, are built on precise synchronization, as are cellular networks, any sort of media streaming, high-frequency trading, power-grid load balancing, and astronomical research, Nijveld noted.

The issue with NTP, Nijveld said, is that it can be easily spoofed, which would cause havoc for any of the other above-listed uses. In a typical man-in-the-middle attack, one could capture a response, change the timestamp, and resend it to the requester, and no one would be the wiser.

Securing NTP is a trivial task, because the payload does not need to be encrypted, Nijveld said. "Time is everywhere, so who cares if it is encrypted or not?" Instead, only proof of authentication is needed to secure a timestamp packet. "We want to be sure that every time I send a request, the response comes from the party that I wanted it to come from." NTS does this work.

NTS is an extension of NTP that includes a TLS key exchange, using the same key exchange infrastructure used for secure web browsing. The client first contacts the server over a TCP connection secured with TLS (using port 4460). The server's existing digital certificate can be used so long as it's signed by a certificate authority trusted by the client.

After a successful handshake, the server sends the client eight unique cookies, each containing the symmetric key established in the handshake. The client includes one of these cookies in a separate NTP request packet (sent via UDP port 123). Multiple cookies are used in case of dropped packets, with the server supplying a new one in each response. When the server receives the time request, it decodes the cookie to retrieve the symmetric key, and verifies the packet's checksum using the Message Authentication Code (MAC). If the operation is successful, the server sends back an NTP packet with the current timestamp (and a new cookie). Once the key exchange is established, the client can then poll the server on regular time intervals using the stream of cookies. No additional handshakes are needed.

Slow adoption for NTS

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.

The Simple Network Time Protocol (SNTP) is widely used by embedded devices because of its small footprint. It uses a single time source, rather than multiple time sources, and messages are sent over UDP. Nijveld said that he is not aware of a single implementation of SNTP that supports NTS.

He suspected that the NTS-supporting implementations are not widely adopted as device designers may prefer the lighter SNTP clients, even though the other clients are not that heavy. To help spur wider adoption of NTS on Linux distributions, other Trifecta staff are also working on a patch for systemd-timesyncd.

Learning how to scale NTS

Trifecta surmised that one roadblock thwarting the wider use of NTS is the lack of practices to deploy NTS for large-scale usage. In particular, NTS needs to work nicely with pool.ntp.org. This service is run by a virtual cluster of about 5,000 servers. Today, most servers and other machines that use NTP probably have a client configuration pointing to pool.ntp.org. When a request is sent to pool.ntp.org the authoritative DNS server, GeoDNS maps the client to the nearest time server. That time server will then fulfill requests for the current time for that client.

Grafting TLS onto pool.ntp.org would require either issuing certificates to all 5,000 servers or sharing a single certificate across all of the servers. Issuing individual certificates is not feasible as they all share the same domain name, Nijveld said, and sharing a single certificate would be a security nightmare. The whole setup could be compromised by one leaked certificate. "We need alternative approaches."

Trifecta is currently experimenting with two different approaches. One rethinks the server-side service and the other changes the behavior of the client. The proposed server-side change is a load-balancing proxy, with a single certificate, that handles all the server-side encryption. It terminates the client connections, giving the client an encrypted cookie, which is passed to the time server for quick validation. This way, the time servers don't get bogged down with key exchanges. The other approach requires modifying the client to do DNS Service Record (SRV) lookups, which would point to specific self-registering servers, each with its own unique domain name—and its own certificate. This approach requires DNSSEC validation, otherwise addresses could be spoofed "because DNS itself is also not encrypted".

There are still unresolved issues, and open questions, with those approaches. Nijveld didn't say this, explicitly, but equipping a pool of 5,000 servers with digital certificates, as the SRV approach takes, could be prohibitively costly. But if either or both architectures work, they will be submitted to the IETF for ratification.

Currently, Trifecta is looking for volunteers to add their own clients and servers to Trifecta's experimental NTS-only pool. To participate, a client or server needs to be online 24/7 with a fully qualified domain name, and the ability to accept certificates (NTS software can act both as a server and a client). The documentation says that it is possible to use Chrony, ntpd-rs, or NTPSec. However, Chrony requires modification for this.

Those who register with the program will get a token to validate their client to the pool, which needs to be added to the software's configuration file. The client will be given a set of upstream sources to connect with. If set up correctly, the participating time client/server gets a score, which increments each time it successfully executes. The score is used as part of the monitoring system.

Readers who would like to follow along with the work-in-progress management system for NTS servers can find the code on GitHub, and watch the Trifecta Tech Foundation blog for updates.

Index entries for this article
GuestArticles	Jackson, Joab
Conference	FOSDEM/2026

to post comments

This does not seem hopeful

Posted Feb 25, 2026 15:25 UTC (Wed) by nim-nim (subscriber, #34454) [Link] (8 responses)

I suppose some of the financing comes from the industry, because all of this reeks of the approaches favoured by big companies (that tend to fail abysmally in the field).

The first approach fundamentally misunderstands the way pools ensure reliability, with a nice SPOF proxy that would effectively gift time keeping to big cloud providers.

The second approach introduces completely un-necessary reliance on DNSSEC. A client has absolutely no need to protect against spoofed addresses. If the address is spoofed who cares existing cookies won’t work. If the address is spoofed before cookie attribution again, who cares (it’s not as if in a word of let’s encrypt one would be able to trust a random certificate anyway).

The client does not need un-spoofable DNS it needs to contact enough members of the pool (preferably, over differing ASes) to cross-check their responses and detect liars (that sometimes will be just broken systems). Introducing DNSSEC is the usual corporate fail where it is better to fail via approved channels than succeed with (dangerous!) un-approved parties. By all means add a way to lockdown the certificates a client accepts to talk with, but that lockdown should not be the keystone of your security. Especially when trivial cross-checking of time sources is sufficient to detect lies.

This does not seem hopeful

Posted Feb 26, 2026 11:54 UTC (Thu) by kleptog (subscriber, #1183) [Link] (6 responses)

While I don't disagree with you, do you have some suggestions for better solutions? It does seem like a generally hard problem.

This does not seem hopeful

Posted Feb 26, 2026 12:21 UTC (Thu) by farnz (subscriber, #17727) [Link] (5 responses)

The problems aren't technical, at this point, they're social. The resource cost of talking to 3 NTP servers instead of 1 is already deemed "too high" by the devices people care about; how are you going to convince someone that they should pay the resource cost of any form of security, when they're unwilling to pay the resource cost of sending 3 packets and choosing the best reply?

Personally, I think the best approach would be to fix the NTS/pool.ntp.org interaction issue. My personal approach would be for the pool to assign you a hostname for NTS purposes, and a certificate based on that hostname (so time.example.org gets the hostname time.example.org.pool.ntp.org), and use SRV records for pool.ntp.org itself, pointing each client to the pool hostname for that server. Then, with this migration done, I can verify that the hostname I'm seeing ends pool.ntp.org, and that the certificate I've got is from pool.ntp.org - signed by the pool.ntp.org intermediate. You'd need some co-operation with an entity like Lets Encrypt so that the pool certificates are also signed by a trusted root.

The hard part there is the infrastructure to distribute certificates to the volunteers securely, such that you can only get a certificate for time.example.org.pool.ntp.org if you are the operator of pool.ntp.org (already trusted) or the operator of time.example.org. But that's the hard part of any solution.

This does not seem hopeful

Posted Feb 27, 2026 10:35 UTC (Fri) by nim-nim (subscriber, #34454) [Link] (4 responses)

> The problems aren't technical, at this point, they're social. The resource cost of talking to 3 NTP servers instead of 1 is already deemed "too high" by the devices people care about; how are you going to convince someone that they should pay the resource cost of any form of security, when they're unwilling to pay the resource cost of sending 3 packets and choosing the best reply?

You forgot to add that the resource cost of talking to 3 NTP servers is just cargo culting from the dawn of the internet. No modern hardware, able to talk to a TCP/IP network, is so constrained that presents any problem. Most if not all of them will have fat networking channels to at least download firmware updates because direct in-field update via a dedicated service port is orders of magnitude more expensive in a networked world, and writing solid firmware is also a lot more expensive than mostly-working-will-update-if-there-is-a-bug firmware. Mostly-working-will-update-if-there-is-a-bug firmware almost always implies a full https stack somewhere on the device. It is absolutely laughable to pretend full ntp is “too expensive” when you already paid the cost of an https stack.

The cost is not device-side it is central time-keeping side. For reliable timekeeping people need to provision pools of timeservers. device people hate that with a vengeance. They want the money to go into the devices, not into something else. They can barely stand the single time source of SNTP and just want it to scale to zillion devices without expanding its footprint.

This does not seem hopeful

Posted Feb 27, 2026 12:52 UTC (Fri) by taladar (subscriber, #68407) [Link]

And if there are devices that are really so constrained they are likely not running on a network where they talk directly to an internet NTP server anyway, they would likely be industrial sensors or similar devices that are in a subnet where some higher performance device run by the same organization is the gateway to the wider network.

This does not seem hopeful

Posted Feb 28, 2026 8:50 UTC (Sat) by kleptog (subscriber, #1183) [Link] (2 responses)

OTOH, requiring 3 servers introduces an availability issue.

We actually ran into this recently where something in ntpd changed such that if you only configured two servers in the config file it would start up successfully but never actually sync the time. We didn't notice straight away but once we did we simply replaced it with chrony and moved on. I'm still baffled why a program would violate the POLA like that. Either fail or work, not appear to be running but actually broken.

Why only two servers? Because in a fleet of servers in a data centre it is more important that all the servers drift consistently, rather than matching the outside world. So you setup two NTP servers and direct everything else to them. Three is overkill is this situation.

For most devices, millisecond accurate time isn't required anyway. Something that gives you +/- 1 second 99.999% of the time is more than enough. Hence, SNTP.

This does not seem hopeful

Posted Mar 1, 2026 8:56 UTC (Sun) by nim-nim (subscriber, #34454) [Link]

Really just deploy a third ntp server and move one. It’s not a huge cost. High availability requires a quorum (hence 3 not 2 nodes).

The actual huge cost is moving the rest of IT services from old A/B disaster/recovery logic to high availability logic. It’s cheap ntp-side not so cheap everywhere else. The end result should not be more expensive than disaster recovery (you only need to provision 3×1/3 load if you accept 1/3 loss in case of disaster, compared to 2×1 for old A/B) but it’s a lot of (expensive) technical work to load balance properly and hybrid can be a money sink (people try 3×1 because they do not trust their balancing and *that* plus the costs of changing the logic is prohibitive).

When you can switch part of your infrastructure to HA without going hybrid elsewhere just do it. You can switch timekeeping to HA.

Maybe companies will manage eventually to convert legacy A/B to HA; maybe, greenfield HA will end up gobbling everything else. The end result benefits are clear the path to those benefits not much so. HA benefits were a lot less clear when they required building your own 3rd datacenter and before containers enabled fine allocation of hardware capabilities.

This does not seem hopeful

Posted Mar 2, 2026 10:11 UTC (Mon) by farnz (subscriber, #17727) [Link]

The thing is that, in that situation, SNTP is the wrong tool; SNTP says that you don't care about clock drift, just that the time is accurate to about a minute or so. This is because SNTP (by design) does not attempt to discipline the local oscillator to match the time service.

For in-datacentre use, where it's important that the servers all agree, but not that time matches an external source (such as NIST), there's PTP (IEEE 1588), which is based around the idea that you own a grandmaster clock that's the authoritative source for time, and your clock distribution is about having all the clocks match the grandmaster as closely as possible, not having them match your watch as closely as possible.

This does not seem hopeful

Posted Mar 7, 2026 14:55 UTC (Sat) by rubennn (guest, #182647) [Link]

I'm the one who gave this talk. The article is not quite right in how they describe the two approaches. First, we need to consider how NTS actually works: NTS works by initially doing a key exchange phase (NTS-KE). This key exchange phase is there to do about four things: first establish the identity of the server you are communicating with (via PKI/TLS). Second is setting up some shared symmetric keys between the client and the server, NTS-KE extracts the TLS session keys for this. Third is getting an initial set of cookies. These cookies are opaque 'bags of bytes' for clients, but actually contain information that the server uses to reconstruct the session state (i.e. the symmetric keys and anything else it needs), this means that the servers don't actually store any state themselves but basically want the client to keep it for them. By default you get eight of these cookies. They are to be used only once. Finally, the NTS-KE server gives an address to the client for a regular NTP server (or if not given, NTS by default uses the same DNS name as the server, but then just on the regular NTP port 123 instead of the NTS-KE port 4460).

So, once the NTS-KE is completed, the client just sends an NTP packet, adds replay protection random bytes, a cookie, and signs the whole message. All of these extra pieces of information can be sent in NTP extension fields, so for all intents and purposes the NTP packets sent are just regular NTP packets with a little bit of extra information. The server extracts the session state from the cookie, does its timing related stuff, and sends back an NTP packet. This time, the packet contains an additional field that also contains a new encrypted cookie, so that the client can replenish its cookie jar. There is also a mechanism to request additional cookies, so in theory you should never run out of cookies and you should never have to do another NTS-KE again, in practice you will want to do a refresh every once in a while though.

So, lets get back to pooling from this: our first proposal is to intercept the NTS-KE handshake, and then forward that to a pool member server. That does mean that the pool server does the TLS session key extraction on the server side, so when we forward the connection to a pool member server we actually include the extracted session keys. But beyond sending the response back to the client, the pool server has no say over how the cookies are created. This might sound a little bad (we're basically MITM-ing the connection), but in effect this is not that much different to how the current NTP pool operates: it could also send you to a completely arbitrary server anyway, or send you to its own server anyway. So you need to trust the pool operator either way. Additionally: because the pool is only in the way during the NTS-KE, beyond that we have no interactions with clients, so the pool can go offline all it wants, as long as existing clients don't loose their cookies, they will operate just fine.

That is a little bit worse than the current NTP pool: it can also rely a little bit on DNS caching when it goes offline, but the TTLs for the current pool are pretty low as well, so it won't take that much time until new clients notice the pool going offline. Another thing to note here is that the design is still pretty easily horizontally scalable, so that the entire pool going offline should happen less frequently. That said: there is definitely a worry here that this doesn't scale well enough that we as a non-profit can run this indefinitely without significant cash injections, but we'll need to build operational experience to say anything meaningful about that. Another worry is of course that we would eventually have to depend on a commercial party for DDoS protection, which is also something we'd preferably not have to do, but again something we'll have to build operation experience on. We're specifically trying to keep this as simple as possible.

As for the second proposal: the issue here is that if you don't do DNSSEC, who prevents your ISP or one of the intermediate recursive resolvers from just sending you their own time sources instead of ones in the pool? Or even worse, someone on your local network could also just as easily manipulate the DNS response to redirect you to specific servers. So your client might think that its correlating time from different time sources, whereas in fact those are all just the same server. So we could remove the DNSSEC requirement a little bit by saying that you as a client can use DoH or DoT and as long as the recursive resolver you are connecting to does proper DNSSEC validation then its all fine. But for now we just chose to keep this as simple as possible, because we currently don't have a good way to guarantee that someone you trust at least did the DNSSEC validation.

All of this is explicitly not about locking down certificates to specific approved ones. This is all about us not trusting (with good reasons I believe) the public internet. So we want to give your client the power to at least detect that its being manipulated. With the current NTP pool that is just not possible, which opens you up to manipulation, without your NTP client ever knowing about it, even if it was a full NTP client and not a 'dumber' SNTP client.

NTS

Posted Feb 25, 2026 16:58 UTC (Wed) by clugstj (subscriber, #4020) [Link] (38 responses)

If you really care about time, you use a GPS receiver, not NTP from random sources on the Internet. This smells of a solution looking for a problem.

NTS

Posted Feb 25, 2026 18:26 UTC (Wed) by erwaelde (subscriber, #34976) [Link] (33 responses)

Well, GPS spoofing is not unheard of e.g. in the Baltic Sea area these days. Spoofing VLF time radio (e.g. DCF77) is not entirely difficult either. So enhancing a time sync protocol does not seem like a complete waste of time to me.

NTS

Posted Feb 26, 2026 1:47 UTC (Thu) by Nahor (subscriber, #51583) [Link] (4 responses)

I thought the same thing, then I read that NTP Stratum 0 can be not only atomic clocks, but also GPS receivers and WWVB/DCF77 radios.
So any GPS/radio spoofing/jamming risk is already embedded in NTP, and NTS will not fix that. Using GPS directly won't add a new attack vector and it would remove NTP as an attack surface, making you more secure overall (*).

(*) that said, NTP does mitigate the GPS risk by allowing more than one NTP servers, most of which wouldn't be affected by a localized GPS spoofing (too far away from the spoofer, or because they don't use GPS in the first place), while using a GPS receiver directly creates a single point of failure.

NTS

Posted Feb 26, 2026 10:36 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (3 responses)

GPS is not a valid clock source for stratum 0, which consists solely of atomic clocks, because they are the one and only reference. GPS synchronizes to those, making ntp servers using it as clock source stratum 1.

Attackers who want to spoof GPS to manipulate the time signal of their victims will have their work cut out for them, because one usually doesn't connect to stratum 1 directly, either. Plus, I am pretty certain that responsible NTP providers have measures in place to check plausibility of their source signal.

NTS

Posted Feb 26, 2026 18:02 UTC (Thu) by Nahor (subscriber, #51583) [Link] (2 responses)

> GPS is not a valid clock source for stratum 0, which consists solely of atomic clocks

I think you misunderstood the documentation you linked. Stratum 0 is the *hardware part* generating a clock signal. It can be an atomic clock but also a radio emitter or a GPS satellite (which is basically just an atomic-clock-in-space). There are no NTP server at stratum 0, only clock sources.
NTP servers start at stratum 1. They get the clock signal in some way (RS-232, airwave, ...) and publish it via NTP.
So yes, GPS is at the same stratum as atomic clocks.

> one usually doesn't connect to stratum 1 directly, either [...] I am pretty certain that responsible NTP providers have measures in place to check plausibility of their source signal.

There are plenty of open-access stratum 1 servers. And who knows what server someone willing to bother with a GPS receiver would use?
But what measure are you thinking about? Most likely is just querying more than one server, which is what I said in my asterisk note.
If not, if the measures don't use NTP, you can't compare "just a GPS receiver" with "NTP + other measures", you can only compare "GPS" vs "NTP" or "GPS+measures" vs "NTP+measures".

My main point remains. The risk of GPS spoofing does not make you inherently less secure than using NTP. GPS spoofing is also a risk in NTP.
But I agree that NTP might be easier to secure (once NTS is widely available that is)

NTS

Posted Feb 26, 2026 21:16 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (1 responses)

OK, I forgot for a second that GPS satellites have their own atomic clocks.

As for the plausibility checks, monitoring clock drift is built into every NTP implementation. Even the menial RTC of a laptop suffices to check if there is a sudden change in drift. Also, time is everywhere. If push came to shove, some steam punk could hack an image processor that can read the hands of a swiss wall clock, to be extra certain; yes, a grandfather's clock, of sort, because reading digit would be too easy. Heck, do both; redundancy!!1! ;)

GPS spoofing is made up, remains my point. Also, NTPv4 has Autokey, so I don't know where the speaker got the idea that there is no authentication. SNTP is a different story, but it's also meant to be simple. I think some people are desperately looking for a problem for their solution, indeed. Last I checked, ntp.ubuntu.com resolves to seven IP addresses for my location. And those are supposedly the nearest ones, which means they differ between potential victims. Systemd-timesyncd picks one of those at random, or rather, the DNS reslover does; don't know if it ever shuffles them, but I guess not. If I felt less at ease I could just install chrony or ntpd, which provide the full suite of NTP, including auth, which predates NTS by 10 years. Plus, they can query multiple servers and try hard to measure the reliability of the source, be it a hardware device or are server.

And last but not least; again, if the attacker is a MITM that can just manipulate traffic at will, like the intro suggests, they could just DoS NTP for us, no matter what. And just throwing NTP responses at unsuspecting clients at the exact predictable time is a bogey man story.

NTS

Posted Mar 1, 2026 21:34 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

Update

Systemd-timesyncd picks one of those at random, or rather, the DNS reslover does; don't know if it ever shuffles them, but I guess not.

Apparently, I was wrong. I've just checked again with timedatectl timesync-status and saw a different IP than when I wrote the above comment. But that may be an illusion, because it may be the DNS resolver doing the shuffling; I was half-expecting that timesyncd was reusing the IP from the initial DNS query, but it obviously doesn't, which is just one more nail in the coffin of outlandish threat models.

Do it in hardware

Posted Feb 26, 2026 2:46 UTC (Thu) by jreiser (subscriber, #11027) [Link] (5 responses)

Build a crystal-controlled oscillator at 15,734 Hz, the horizontal sync frequency of a TV. Digitally divide it down to 1 kHz. Make a PCI card, or a USB-2.0 device. Once per week, sync to a known-good radio reference (WWVH, CHU, etc.) and then sync the PC clock to the result.

Do it in hardware

Posted Feb 26, 2026 11:53 UTC (Thu) by nowster (subscriber, #67) [Link]

Crystals drift quite a bit due to thermal effects.

Why use the TV horizontal scan frequency? I don't know of anyone who makes crystals for that.

However, 32768Hz crystals are very common (every digital watch has one, and the RTC on a PC's motherboard probably has one). With very careful tweaking of the trimmer capacitors you can get an average drift of about a second a month. Thermal cycling will mean that the instantaneous frequency is less accurate.

The Linux kernel will handle the frequency/phase compensation part automatically when its clock is disciplined by an NTP source. It's had that ability for over 20 years.

But you can do so much better than that. You can get reference frequency (eg. 10MHz or 100MHz) crystal oscillators with thermal compensation or thermally controlled enclosures.

Some GPS references use OCXOs to "flywheel" when there's loss of signal.

However, if you're in that sort of expense range you might as well get an off-the-shelf Rubidium atomic clock.

Do it in hardware

Posted Feb 26, 2026 15:33 UTC (Thu) by dskoll (subscriber, #1630) [Link] (3 responses)

Or you could buy your own atomic clock reference. A bargain at under $3000.

Do it in hardware

Posted Feb 26, 2026 18:13 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link] (2 responses)

You can buy used rubidium oscillators for about $300-$500. I have one, I couldn't resist buying it a few years ago. It works great in the 1PPS mode, and I integrated it with NTP. But it uses 50W constantly.

Do it in hardware

Posted Feb 26, 2026 21:06 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

But it uses 50W constantly.

So that's in the same general range of power consumption as a spare refrigerator. It would be a noticeable but manageable expense for a home user but a tiny drop in the security bucket for a big company.

Do it in hardware

Posted Feb 26, 2026 21:54 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Yup. And a full-blown rack-mounted NTP server with built-in redundant oscillators is around $8k, capable of serving thousands of requests per second.

NTS

Posted Feb 26, 2026 13:16 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (21 responses)

Spoofing GPS is not the problem in the Baltic Sea; jamming is. Actually spoofing a positional reading is harder because it still needs to be plausible. Thus an actual spoofed GPS signal, which would need to involve at least four emitters of false signals, is still close enough to the real time, otherwise the position would be miles off. Being off by one second means the resulting vector is off by 300,000 kilometers (let's keep it simple and not drag Einstein into this; I know it's more complicated, but irrelevantly so for this matter). So even a spoofed GPS time would still be good enough for cryptographic purposes.

Also, how would the attacker ensure that his signals are used instead of being discarded as implausible garbage? Jamming precludes spoofing, so jamming the others is impossible. So I highly doubt any such attacks on GPS exist; jamming is good enough to render the target blind; they need to go old-school.

NTS

Posted Feb 26, 2026 15:37 UTC (Thu) by malmedal (subscriber, #56172) [Link] (20 responses)

> Jamming precludes spoofing, so jamming the others is impossible.

No, your jamming can be set so it does not interfere with the spoofing signal you want to send. Even the US military is vulnerable to replay-attacks on GPS.

NTS

Posted Feb 26, 2026 20:30 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (18 responses)

I believe it when I see it. Explain how. You need to block all other sources in the same spectrum as yourself. Maybe you can up the power and drown out the others but then the US military is stupid for trusting it, because the signal strength is implausible.

And what would they achieve by spoofing positions? Again, plausibility. A ship doesn't suddenly drift without any action of the captain, to stay with the naval example. All spoofing achieves is that they realize GPS don't work and fowl play is afoot. So why not jam them outright? The outcome is the same.

NTS

Posted Feb 27, 2026 3:05 UTC (Fri) by malmedal (subscriber, #56172) [Link] (15 responses)

> I believe it when I see it.

It was very noticeable in Gdansk when I visited last year. Feel free to visit.

> Explain how.

http://www.diva-portal.org/smash/get/diva2:1856297/FULLTE...

> And what would they achieve by spoofing positions?

For instance Iran managed to capture a US drone by spoofing GPS and tricking it into flying into their airspace.

NTS

Posted Feb 27, 2026 6:09 UTC (Fri) by PeeWee (subscriber, #175777) [Link] (3 responses)

And what would they achieve by spoofing positions?
For instance Iran managed to capture a US drone by spoofing GPS and tricking it into flying into their airspace.

Where is the evidence for that? Just jamming GPS could have achieved the same, by forcing limp-home-and-land-ASAP mode. Or by plain old hijacking of the command and control stream. The latter seems the more likely explanation, because it's really hard for a hypothetical GPS spoofer to know when its remote pilot wants to land it, and where. The GPS spoofing attack story sounds a lot like scuttlebutt, maybe even spread deliberately; you don't sell very many drones with known insecure command and control, but GPS spoofing is just an "act of god, nothing we, or anyone, could have done about that!1!! Now, where do we send the invoice?"

NTS

Posted Feb 27, 2026 7:44 UTC (Fri) by malmedal (subscriber, #56172) [Link] (2 responses)

> !1!!

I provided a document that will help you learn about the subject. I would suggest you do that and ask about specific things you don't understand instead of continuing your argument from ignorance.

NTS

Posted Mar 2, 2026 0:27 UTC (Mon) by PeeWee (subscriber, #175777) [Link] (1 responses)

You provided a big pamphlet, alright; not falling for this "educate yourself(!)" trick, which is a classic conspiracy nut move.

NTS

Posted Mar 2, 2026 0:55 UTC (Mon) by corbet (editor, #1) [Link]

Folks, maybe we've had about enough of this thread...please?

NTS

Posted Feb 27, 2026 6:33 UTC (Fri) by PeeWee (subscriber, #175777) [Link]

And the point is still that GPS spoofing is just an outlandish threat model in terms of NTP. Individual victims cannot be easily targeted and the spoofed server will most likely pull its own plug when evaluating its stats, but other NTP servers will definitely spot it as an outlier, so the fallout for the whole NTP (pool) network is limited. And that scenario only flies when explicitly targeting NTP, ruling out a collateral damage type scenario when someone wants to "hijack a drone". Otherwise, again, the time difference would be negligible for crypto purposes.

NTS

Posted Feb 27, 2026 7:32 UTC (Fri) by PeeWee (subscriber, #175777) [Link] (9 responses)

(forgot this)

I believe it when I see it.
It was very noticeable in Gdansk when I visited last year. Feel free to visit.

I don't doubt that GPS got jammed; any radio communication can be. Or were you directed into the Baltic Sea by your navi?

http://www.diva-portal.org/smash/get/diva2:1856297/FULLTE...

Oh, I did not say, one couldn't try and build a spoofer; just that it will very likely fail against a real target outside the lab. See section 5 of that paper, for instance:

In conclusion, both spoofing methods effectively create the illusion that the victim receiver is moving.

And there's the rub, as I said elsewhere. Ships don't move on their own; sudden course changes without input ring alarm bells. Plus, to have such fine-grained motion, the time signal must be close enough to the real time, hence the irrelevancy for crytpo; no TOTP DoS to see here, move along. And that's glossing over the other challenges in the real world, like trying to force the receiver into believing the attacker, even listening to them. Lot's of moving parts that had to be kept steady in lab conditions to even prove the concept; and ignoring of real world problems:

For example, the victim receiver used in our project normally can acquire six or seven satellites at the first time and the number of tracking channels increases gradually. They often engage in continuous acquisition attempts. However, our choice of employing the serial search algorithm, which is the most time- consuming, on real-time signals makes it impractical to perform multiple acquisitions.

IOW, victim cooperation required, and lots of it.

And that's the last I am going to say about the GPS "issue", which may very well qualify as stunt crypto attack [PDF] (page 9); not quite but close enough. This is about NTP and not GPS as a positioning system; the former only (ab)uses the time signal of the latter; it's like buying a car for its stereo.

NTS

Posted Feb 27, 2026 8:42 UTC (Fri) by malmedal (subscriber, #56172) [Link] (8 responses)

> Or were you directed into the Baltic Sea by your navi?

Switching off cellular radio and leaving GNSS on my phone would show a position some 100km away. If the phone can see a celltower it will know where that is.

> sudden course changes

Obviously you need to make believable changes if you want the spoofing to work.

https://www.lloydslist.com/LL1128820/Seized-UK-tanker-lik...

> victim cooperation required, and lots of it.

No. Are you being serious? Please read the very next paragraph.

NTS

Posted Feb 27, 2026 9:08 UTC (Fri) by malmedal (subscriber, #56172) [Link] (2 responses)

The claim that Iran spoofed the drone is detailed here btw:

https://www.csmonitor.com/World/Middle-East/2011/1215/Exc...

NTS

Posted Mar 1, 2026 20:56 UTC (Sun) by PeeWee (subscriber, #175777) [Link] (1 responses)

"By putting noise [jamming] on the communications, you force the bird into autopilot. This is where the bird loses its brain."

Sounds a lot like what I initially said: force limp-home-and-land-ASAP. The rest reads like a journalists who doesn't understand the subject matter putting words in the mouth of the interviewee.

Since this is still utterly irrelevant to NTP, that'll be the end of my part.

NTS

Posted Mar 2, 2026 2:47 UTC (Mon) by malmedal (subscriber, #56172) [Link]

> Sounds a lot like what I initially said

It does not, you keep claiming that GPS cannot be spoofed. This was the command and control being jammed, and then GPS was spoofed so the bird tried to land at what it thought were its home base.

NTS

Posted Mar 1, 2026 21:02 UTC (Sun) by PeeWee (subscriber, #175777) [Link] (1 responses)

Obviously you need to make believable changes if you want the spoofing to work.

Which is exactly my point. Even allowing for such outlandish attacks on GPS, it is totally irrelevant to NTP purposes, because the time differences are bound to be in the very low fractions of a second. Again, light travels a 300,000 km per second. And the vectors are calculated from the time it took the signals to reach the receiver, knowing the exact orbit location of the sources.

/EOD

NTS

Posted Mar 2, 2026 2:53 UTC (Mon) by malmedal (subscriber, #56172) [Link]

> outlandish attacks on GPS, i

They have been successfully executed, but you keep denying that and moving the goalposts.

NTS

Posted Mar 1, 2026 22:33 UTC (Sun) by PeeWee (subscriber, #175777) [Link] (2 responses)

No. Are you being serious? Please read the very next paragraph.

Except that they failed to do the geometry. When you can only control the time signal, the altitude is off, because all distance signals appear to have traveled longer/shorter distances. When you manipulate one of the others, all three space dimensions (longitude, latitude, altitude) are off, because one leg of the tree-sided pyramid has the wrong length. And you cannot know nor influence which source the receiver picks for which value in its calculations, even if one of those is under your control; so will it use the spoofed one for one of the (at least) three distance vectors or will it be used as the time to sync to?

You are reading way too much into this. That's an academic paper written by people constantly hunting for grant money. Theses days, one needs to make headlines to be relevant in any field of study. And that's what you get, when it's "publish or perish!" Plus, one must never underestimate the element of disinformation in all matters even remotely military. So you should really think at least thrice(!) before believing easily accessible public information. That goes both for that Iranian engineer, "spilling the beans", as well as papers from state-affiliated institutions. As a rule of thumb, if it ought to be classified as a military secret and you are reading about it on the open internet, chances are that's no accidental leak. For instance, it may be beneficial for Iran to lead the US military on a wild goose chase. It may also be beneficial for the US to have the world run with the story. And maybe this paper is all for the benefit of China - "see, we can spoof GPS!1!!" -, so they now have to "close the gap". It's Cold War 2.0, after all.

And with that, I am really out of this sub-thread.

</off-topic>

NTS

Posted Mar 2, 2026 3:08 UTC (Mon) by malmedal (subscriber, #56172) [Link] (1 responses)

> That's an academic paper written by people constantly hunting for grant money. Theses days, one needs to make headlines to be relevant in any field of study. And that's what you get

It's amazing how you can be so insulting and trivially wrong, it's actually a student project.

Now try actually reading the paper.

NTS

Posted Mar 2, 2026 3:25 UTC (Mon) by corbet (editor, #1) [Link]

Second time: please bring this to an end, this discussion has gone far past any usefulness.

NTS

Posted Mar 1, 2026 23:36 UTC (Sun) by JdGordy (subscriber, #70103) [Link] (1 responses)

I was in Israel in november and my GPS was very obviously being spoofed (I beleive its a common problem there). My phone basically thought I was at Amman (Jordan) airport instead of in the Haifa region. https://photos.app.goo.gl/LLCVTBoTUX7tW28b7 if you want to have a look.

Very annoying for an international traveler trying to navigate an unfamiliar road network.

NTS

Posted Mar 2, 2026 0:22 UTC (Mon) by PeeWee (subscriber, #175777) [Link]

Sorry, that photo says nothing; no reference landmark. But, assuming that it was as you said, was the time off by a noticeable amount? Because that's the only thing of interest in the NTP context; see my other comments to that effect.

NTS

Posted Feb 26, 2026 20:45 UTC (Thu) by PeeWee (subscriber, #175777) [Link]

(Argh, did it again; wrong button)

Also, how would replay attacks work, exactly? Don't they realize that the time is in the past?

Anyway, the point was, and still is, that even a spoofed GPS time must still be good enough for crypto purposes. That is, if somehow a stratum 2 server, attached to a GPS receiver, were an innocent bystander of a GPS position spoofing attack that doesn't ring alarm bells, right away. And, as I've said earlier, it's very implausible to target individual (S)NTP clients by spoofing GPS time, on the off-chance the victim connects to it. It's also not trivial to not trigger alarms in the NTP service, because it monitors clock drift; image what happens when the clock is going strangely fast or slow all of a sudden.

I am so not worried about such moving parts galore shot in the blue attacks.

NTS

Posted Feb 26, 2026 0:38 UTC (Thu) by ringerc (subscriber, #3071) [Link]

Someone's auditors probably told them that they're using a cleartext protocol, and they can't have that.

Nevermind that there's no meaningful risk, the box isn't ticked.

NTS

Posted Feb 26, 2026 5:05 UTC (Thu) by gdt (subscriber, #6284) [Link] (1 responses)

That was the view prior to the invasion of Ukraine. Now GPS spoofing is an everyday event and GPS measured at just one point doesn't make a good basis for an organisation's network time.

Fortunately, NTP does have the falseticker detection capability, so an organisation with a large physical footprint can simply run four or more NTP servers with GPS receivers across that footprint. It's typical for that organisation's NTP clients to run symmetric encryption to the organisation's NTP servers. Symmetric encryption being secure from certificate shenanigans.

There's a lot of interest in upgrading national 'atomic clock' timekeeping services -- which have often regarded NTP as an ancilliary service -- to be able to scale secure NTP to an entire nation, whilst resisting denial of service attack from a competing nation.

Finally, there's every reason to run a 'canary' NTP client within an organisation. Pulling from national NTP servers, GPS and the public NTP pool and alarming to the corporate monitoring system upon a large discrepancy. As the article points out, NTP is a critical service, and it should be monitored like one.

NTS

Posted Feb 26, 2026 9:12 UTC (Thu) by nim-nim (subscriber, #34454) [Link]

> GPS spoofing is an everyday event and GPS measured at just one point doesn't make a good basis for an organisation's network time

Now consider, what is the natural way of implementing the proxy pool approach ? It’s to put a single expensive GPS card in the central proxy node and distribute the time of this single spoofable card via the proxied nodes. That’ another reason it is a massive fail.

The proxy pool approach results from the (stupid) wish of SNTP implementers to continue using a SPOF-able and spoofable single time source, only bigger so it can take the hit of mass deployments. Because timekeeping is expensive (ah ah ah). They also hate crypto but feel someone will force them to check the crypto box. They have barely evolved past the point of the appliance makers that made their products tributary of smartphone apps (complete with roundtrips to a distant flacky cloud node and regular refusal to work when the maker feels the need to nag you about something), but could not be bothered to use this expensive networking stack to actually set the time of the appliance reliably.

NTS

Posted Mar 7, 2026 14:55 UTC (Sat) by rubennn (guest, #182647) [Link]

A lot of the work we are doing at Trifecta concerning time synchronization is actually specifically about staying away from GPS. What most people tend to forget is how easy it is to jam a GNSS signal because the noise threshold is just so low. Those signals are weak, because otherwise GNSS systems could never work. But by connecting those weak signals to our power grids and our telecom networks, we make those systems vulnerable. Those kinds of systems actually could benefit a lot from getting a strong signal over something that is not so easy to jam. Which is where the internet comes in: if we would be able to send accurate timing signals over the internet in a secure way that could really help loosen our dependency on GNSS for those kinds of systems. So aside from NTS (which is more for the public internet in my eyes), this is also why we're working on security extensions for PTP.

NTS with chrony and netnod.se

Posted Feb 25, 2026 18:25 UTC (Wed) by cortana (subscriber, #24596) [Link]

I have the following in my chrony.conf which is sufficient to use NTS with the netnod.se time service. Maybe someone else will find it useful:

pool nts.netnod.se nts iburst maxsources 2 ipv6
pool nts.netnod.se nts iburst maxsources 2 ipv4

I have dual stack networking and wanted to guarantee that I've always got both IPv6 and IPv4 time sources configured, hence there are two entries. A single pool nts.netnod.se nts iburst line should be sufficient if you don't care.

single-server SNTP considered harmful

Posted Feb 25, 2026 18:34 UTC (Wed) by hmh (subscriber, #3838) [Link] (4 responses)

NTS won't help SNTP if it is doing single-server time selection, been there, had to help clean up the resulting mess.

Most (hopefully not all) SNTP clients cheerfully violate the very first rule of NTP deployment: you ALWAYS need a quorum of at least three servers to set the time. That means you need the client to actually be able to query more than three servers, because one of them might not be reachable and you still need at least three of them, and it also means you must run a quorum algorithm to select what server you will trust.

I'd rate this (proper multiple-server query and quorum-based selection) as *far* more important an issue than NTS support. I speak from experience :-/

single-server SNTP considered harmful

Posted Feb 26, 2026 13:32 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (1 responses)

Most (hopefully not all) SNTP clients cheerfully violate the very first rule of NTP deployment: you ALWAYS need a quorum of at least three servers to set the time.

That's by definition of SNTP; it's a tradeoff. And those rules exist in NTP for precision, not for security. If anything, NTS makes more sense with SNTP than with NTP, because the latter does provide authentication, IIRC.

single-server SNTP considered harmful

Posted Mar 2, 2026 15:00 UTC (Mon) by hmh (subscriber, #3838) [Link]

The quorum requirement in NTP is needed for operational security for anything where it actually matters that the system clock is not set to a wildly incorrect time.

It is not about precision. It is about a single-server NTP or SNTP client having no other choice than to blindly trust a single time server that could be misbehaving, especially when it is bootstrapping time because it has no RTC, or its RTC failed.

When something doesn't have strong requirements on its system clock being at least set to the correct day or hour (or minute, or second), there is no operational security risk on using single-server SNTP.

FYI, I know for a fact (first-hand experience) that a misbehaving ST1 NTP time server will happily serve phase/frequency-accurate, NTS-signed, wildly-out-of-date time (as in months in the past, but there is no reason why it could not have been years in the future, etc).

single-server SNTP considered harmful

Posted Feb 27, 2026 7:52 UTC (Fri) by wahern (subscriber, #37304) [Link] (1 responses)

The default ntpd.conf (OpenNTPD) on OpenBSD includes,

servers pool.ntp.org
server time.cloudflare.com

pool.ntp.org seems to return 4 A RRs, so out-of-the-box ntpd will synchronize with 5 servers (confirmed with ntpctl -s peers). Whether it's using them together properly, I can't say, but at least some SNTP clients will use more than 3 peers in the default configuration.

single-server SNTP considered harmful

Posted Mar 1, 2026 21:23 UTC (Sun) by PeeWee (subscriber, #175777) [Link]

OpenNTPD is not an SNTP client. It's a full-blown NTP server. I believe SNTP is meant for clients only. And maybe it was only envisioned for enterprise deployments, which sport one authoritative in-house NTP server that does everything by the NTP book, e.g. syncing to more than one upstream server.

Does it really solve the problem?

Posted Feb 26, 2026 11:15 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (1 responses)

The threat model is an MITM, so they are clearly able to manipulate network traffic at will. So what good is it going to do if they fail authentication? We still have no time signal and no way of getting it, if they don't let us.

Does it really solve the problem?

Posted Feb 26, 2026 11:31 UTC (Thu) by PeeWee (subscriber, #175777) [Link]

(accidentally sent before adding this)

Detecting spoofed time should also not be too difficult. NTP clients keep track of the drift rate of the local RTC. One can even instruct chrony, for instance, to regularly save that info to a file, so it survives restarts. Then it's just basic math to check plausibility of the received NTP response. Yes, that still leaves embedded devices without RTC vulnerable at boot, but they couldn't check certificate validity either at that time, since they don't have the correct time yet; chicken and egg.

What about Autokey?

Posted Feb 26, 2026 14:11 UTC (Thu) by PeeWee (subscriber, #175777) [Link] (1 responses)

Having just watched the talk, I must say I cannot shake the feeling that this is just sensationalism and hyperbole. I mean, "NTP is fundamentally broken and insecure"? And has never been updated to change that?

I am beginning to think that Trifecta needs a success story to justify their existence; and they are prepared to lie for it!

What about Autokey?

Posted Mar 7, 2026 14:54 UTC (Sat) by rubennn (guest, #182647) [Link]

I hope we can at least both agree that the original version of the autokey protocol (the one released under RFC5906) is broken enough that it shouldn't be used. There are several issues with that version: from using broken hash functions, using cookies and seeds that are only 32 bits long (which is too small) and being vulnerable to MITM attacks. Beyond that, it also is just (in my opinion) an unnecessarily complicated protocol. The page you are referencing explains some parts of how ntpd currently implements their version of the autokey protocol, but as an implementer I have read those pages several times, but have no idea how to get started.

Beyond these things about the autokey protocol, the IETF has also established long ago (RFC3365, BCP61) that protocol designers should always consider whether existing security protocols can fulfill their requirements. In this case, what we're trying to do is the establishment of the server identity and the secure exchange of some key material. This is exactly what a TLS handshake already does. Why invent a second protocol which will have far fewer people looking at it? We already have a protocol that is continuously scrutinized by the security community, where any issues found and resolved in TLS directly benefit the security of NTS/NTP as well.

Even ignoring all of the previous things. Just look at what kind of NTP traffic gets sent across the internet. To be honest, I don't really care in which way NTP traffic gets secured at all. All I care about is that in general NTP traffic on the internet is just not protected. In practice, most computers/devices on the internet rely on an SNTP client, and all of those are very easy to manipulate, because its almost impossible to build in many protections in those kinds of clients. That manipulation can break a whole lot of stuff which currently considers the wall clock time to just be a given, which it simply isn't.

How is NTS certificate validity confirmed?

Posted Feb 26, 2026 14:26 UTC (Thu) by nhippi (subscriber, #34640) [Link] (6 responses)

Stupid question: how does the NTS client establish trust of the validity period of the NTS servers?

If the TLS certificate of NTS server has 90 day validity period and your clock is off by over 90 days - how can the client establish it's own clock is off, rather than the server presenting an outdated certificate?

How is NTS certificate validity confirmed?

Posted Feb 26, 2026 17:48 UTC (Thu) by rgmoore (✭ supporter ✭, #75) [Link] (3 responses)

If the TLS certificate of NTS server has 90 day validity period and your clock is off by over 90 days - how can the client establish it's own clock is off, rather than the server presenting an outdated certificate?

Most computers have a fallback capability of setting the clock manually. If you can't figure out the date accurately enough to get within the expiration window of the TLS certificate, the clock on your computer is the least of your problems.

How is NTS certificate validity confirmed?

Posted Feb 26, 2026 20:04 UTC (Thu) by wahern (subscriber, #37304) [Link] (2 responses)

> Most computers have a fallback capability of setting the clock manually. If you can't figure out the date accurately enough to get within the expiration window of the TLS certificate, the clock on your computer is the least of your problems.

If you include routers, gateways, IoT, etc, then I'm not sure "most" is very accurate. I have an old PC Engines APU gateway with a bad battery backup that I keep meaning to replace. It uses OpenBSD with the native OpenNTPD, and I have to disable the default TLS-based timestamp authentication, otherwise on power failure the VPNs don't come back up.

IME, maintaining clocks is often the biggest headache. I keep meaning to try patching OpenNTPD, or at least write a startup script, to maintain a timestamp file to use as a reference point on cold boots (though I'm not sure how useful this would actually be). But given the long key rotation times for root DNSSEC keys, DNSSEC would really be ideal here. I don't get the vitriol and pushback against DNSSEC; it neatly solves so many issues like this, at least as well as the various ad hoc solutions people devise to avoid DNSSEC. Relatedly, and noteworthy given Let's Encrypt's shift to exclude the client auth key usage bit from TLS certificates, the latest release of Prosody (XMPP server) has native support for DNSSEC for server-to-server connections.

How is NTS certificate validity confirmed?

Posted Mar 1, 2026 21:53 UTC (Sun) by PeeWee (subscriber, #175777) [Link] (1 responses)

I keep meaning to try patching OpenNTPD, or at least write a startup script, to maintain a timestamp file to use as a reference point on cold boots (though I'm not sure how useful this would actually be).

That sound like it would be very useful, provided that the downtime is short enough. It it's too long, though, it may lead to accepting expired certificates.

I don't get the vitriol and pushback against DNSSEC; it neatly solves so many issues like this, at least as well as the various ad hoc solutions people devise to avoid DNSSEC.

The problem with DNSSEC, AIUI, is that it does not really solve anything, may even lure one into a false sense of security. The only thing it authenticates is the relationship between a domain and its IP address(es). But subsequent connections to the IP don't tell you anything about the party you are talking to. The subsequent NTP request goes to the raw IP address, unencrypted and unauthenticated; nothing stopping any MITM there from messing with all of your traffic, no matter the direction, unless one also authenticates that, i.e. cryptographic signatures. Then why did one need DNSSEC in the first place?

And your further reasoning thus explains the pushback, because you fell for the false sense of security.

How is NTS certificate validity confirmed?

Posted Mar 2, 2026 7:21 UTC (Mon) by wahern (subscriber, #37304) [Link]

Protocols that rely on DNSSEC typically use DNSSEC to query or validate application-level public keys. For example, XMPP with DANE/TLSA RRs. Though, in the NTS case DNSSEC is being used to authenticate the list of NTP pool hostnames, but connections to those hosts authenticated using WebPKI. In neither of these two examples is the security false.

How is NTS certificate validity confirmed?

Posted Feb 26, 2026 19:23 UTC (Thu) by farnz (subscriber, #17727) [Link] (1 responses)

There's two options in insecure NTP, and I'd expect comparable options to be present for NTS:

The NTP daemon "panics" and quits immediately if time is too far out (over 1,000 seconds by default in ntpd). This then requires a human to intervene, and set the clock to within 1,000 seconds of real time; running NTS in this mode would not have this problem, since you need to set the time to with 1,000 seconds of the time that your NTP servers give you to get synced anyway.
Assert that the first time step can be large, and don't panic, just sync to the time you've chosen across all your servers

In the second case, where you're ignoring the local clock, you open up room for an algorithm along the lines of "if all my NTP-KE servers have time-invalid certificate chains, then I talk NTS with the servers whose certificate chains are valid but for time expiry. Those servers that take part in NTS with me are considered as candidates, and I sync as normal. Once synced, I repeat the NTS process, but this time, I don't have the special case for all my NTS servers have time-invalid certificate chains".

Note that, just as "ignore how bad my local time is and sync anyway" is dangerous in insecure NTP unless handled with care (since you can confuse things like cron daemons), the automatic thing of "if I have no valid NTP-KE servers, then retry ignoring time" opens up room for badness. But if you had to care about the sorts of problems that can happen, you have other mitigations in place already (noting that NTP-KE is harder to spoof than NTP itself, because it's TCP-based, not UDP-based).

How is NTS certificate validity confirmed?

Posted Mar 1, 2026 22:48 UTC (Sun) by mirabilos (subscriber, #84359) [Link]

openntpd in OpenBSD has a third:

Get an estimate by doing an https request to a somewhat trustworthy or too-big-to-fail server, use the response Date header as a target clocktime, then fine-tune with NTP.

What's wrong with NTP keys ?

Posted Mar 2, 2026 4:08 UTC (Mon) by wtarreau (subscriber, #51152) [Link]

I don't understand what this is trying to solve. I've always been taught to set keys via /etc/ntp/ntp.keys for secure communication. In the past it would only support MD5 but since around 2019 AES-128 is the default. When you manage your own servers, you just use these keys everywhere between them and their communications is supposed to be secure, right ? This might explain why the proposed standard is very slow to be adopted. Or is it only useful for public servers ?