Why NTS Alone Is Not Enough

Network Time Security (NTS) closes the authentication gap at the transport layer. It protects the key exchange over TLS and authenticates subsequent NTP packets against tampering and replay. Deployed against a genuine Stratum-1 server, it is a genuine improvement over unauthenticated NTPv4.

It does not answer the question that matters:

Who is authorised to prove they are your trusted time server?

That question is hidden behind a single configuration line:

server time.provider.com nts iburst

This is not a declaration of trust in one named provider. It is a chain of inherited assumptions. Each assumption is a vector.

Assumption 1: DNS tells the truth

The client resolves time.provider.com before the TLS session exists. It accepts an IP address returned by a DNS resolver on the open network and treats it as the address of the system authorised to define “now.”

In most deployments there is no DNSSEC validation, no pinned address, and no private resolver policy. The off-path DNS cache poisoning vector documented in the previous section applies here directly. NTS does not change this. The TLS handshake happens after the client has already been directed to the wrong address — at which point the authentication NTS provides is applied to the attacker’s server, not the legitimate one.

Assumption 2: A valid certificate proves identity

If the attacker’s server presents a certificate for time.provider.com that chains to a trusted certificate authority, the TLS handshake succeeds. The NTS session is established. The client synchronises to the attacker’s time.

A valid certificate does not prove the server is the intended time authority. It proves that a CA was satisfied by a domain-control validation method — typically a DNS or HTTP challenge over the open internet. Those validation paths are subject to the same DNS manipulation and routing attacks documented in the previous sections. A certificate issued on the basis of a poisoned DNS challenge is technically valid. It is not trustworthy.

Assumption 3: The CA bundle is the trust account

The default public CA bundle trusted by most operating systems contains approximately 150 certificate authorities. By accepting the default bundle, an institution has extended implicit trust to each of those organisations, their internal security controls, their external validation systems, their delegated sub-CAs, and the network paths over which their domain-validation challenges are performed.

None of those organisations were audited by the institution. The bundle was inherited from the operating system vendor.

This is not a controlled trust model. It is inherited internet trust presented as security architecture. For an institution where time integrity is a regulatory requirement, “we trust whoever the OS vendor trusts” is not an acceptable chain of custody.

Assumption 4: Detection undoes the damage

Certificate Transparency logs, revocation, and root-store governance are legitimate controls. They operate after the fact. If a client accepted a fraudulent certificate during the attack window, the NTS session was already established with the wrong server. The time was already trusted. Finding the certificate in a transparency log the next day does not undo the drift. It does not restore the timestamps that were written during the attack window. It does not make the audit trail forensically defensible.

The residual risk

An institution that deploys NTS against a public provider with a default CA bundle has narrowed the attack surface. It has not validated its time authority. It has delegated that decision to 150 organisations it did not vet, operating validation infrastructure it does not control, over network paths it cannot observe.

For infrastructure where time integrity is a regulatory requirement — where audit trails must be forensically defensible, where timestamps are evidence in disputes, where NBC TCRMG requires documented chain of custody — that delegation is the residual risk. NTS as typically deployed satisfies neither the jurisdictional nor the forensic requirements the previous sections established.

CNX Precision Time replaces the 150-CA public bundle with a single private root CA dedicated exclusively to the time service. The institution installs the CNX root anchor once — from that point, the TLS handshake accepts only certificates that chain to CNX. A compromised public CA, regardless of which one, cannot produce a certificate this client accepts. DNS is removed from the synchronisation path via a local pin, closing the pre-TLS poisoning vector. The trust question has one answer: one CA, one operator, one jurisdiction. The full architecture is in How CNX Addresses Each Vector.