Meta's public time service adds NTS-authenticated NTP with stateless servers

Meta's time service can now prove itself

Meta has switched on Network Time Security (NTS) for its public time service, according to a post on the company's engineering blog that reached the front page of Hacker News. Clients connecting to nts.meta.com can now cryptographically verify that the time they receive actually came from Meta and was not modified in transit — a guarantee plain NTP, unauthenticated since 1985, has never offered. Meta has also open-sourced the stack, including the server and a client available through its Time library on GitHub.

Why unauthenticated time is a problem

Meta's argument is that NTP is not just another insecure legacy protocol: time is the input every other security decision is measured against. Certificate validity windows, token expiry, replay windows, and log ordering all depend on the local clock, and the check is circular — you cannot validate a certificate's notBefore and notAfter bounds without already trusting your clock.

The post ties this to shrinking certificate lifetimes. Under CA/Browser Forum ballot SC-081v3, the cap on newly issued publicly trusted TLS certificates fell to 200 days in March 2026, drops to 100 days in March 2027, and reaches 47 days in March 2029, with domain validation reuse falling to 10 days at that point. At 47 days, manual certificate management stops being viable at any scale, renewal becomes a roughly monthly unattended ACME loop, and a host with a skewed clock reissues or fails on a schedule nobody is watching.

How NTS works

NTS, standardised in RFC 8915, splits authentication into two phases.

The first phase is a key exchange (NTS-KE) over TLS 1.3 on TCP port 4460, negotiated with ALPN ntske/1. Client and server agree on an AEAD algorithm, derive two directional session keys directly from the TLS session using the RFC 5705 exporter, and the server issues eight cookies plus a record naming which NTP server to use. This happens once, not per packet. Meta negotiates three AEADs — AES-SIV-CMAC-256, which RFC 8915 makes mandatory to implement, plus AES-SIV-CMAC-512 and AES-128-GCM-SIV — with client preference winning.

The second phase is ordinary NTPv4 over UDP port 123 with NTS extension fields. Each request carries a unique identifier, a cookie, and an authenticator that covers everything before it but encrypts nothing. The server opens the cookie to recover the session keys, verifies the authenticator, and replies with the identifier echoed back plus an authenticator of its own, which carries fresh cookies encrypted inside it.

Meta's servers never send an NTS NAK, so a forged packet is indistinguishable from packet loss and cannot be used to push a client into a fresh key exchange. Replays fail because the echoed identifier matches no outstanding request. And because replacement cookies travel inside the encrypted authenticator rather than in the clear, an observer sees a different opaque blob on every exchange and cannot follow a client between networks.

Cookies without state

A cookie is server state handed to the client for safekeeping: the session keys, sealed with AES-SIV so only a server can open them. The obvious implementation would replicate a key ring to every server, which turns a time service into a distributed state problem.

Meta instead derives each day's sealing key from a shared master secret using HKDF-SHA256, with the day number — whole 24-hour periods since the Unix epoch, so no timezones or daylight saving — as the salt. That integer doubles as the cookie's key ID and travels in the clear, meaning any server can re-derive the key and open a cookie it has never seen, including one sealed by a host it has never talked to. Servers accept cookies from two days back and one forward to cover skew around rotation boundaries. The result, per the post: no key ring, no replication, no session table, no shared state to fall out of sync, and nothing for an attacker to exhaust. Key-exchange servers and NTP responders are separate machines that never exchange anything, and the unauthenticated NTP path is untouched.

One line of chrony

Chrony users can enable it with a single directive: pool nts.meta.com nts iburst maxsources 5. Meta recommends pool over server because the configured host is not the host you end up talking to — nts.meta.com terminates key exchange only and steers clients to time.meta.com responders — and NTP wants several independent sources that can outvote a bad one. Each association runs its own key exchange, and the post's chronyc authdata output shows five independent authenticated sources from that one config line.

Why it matters

Time sync is usually treated as plumbing, but it underwrites certificate validation, credential expiry and replay protection, and the move toward 47-day certificates assumes unattended renewal loops running on trustworthy clocks. Meta's stateless cookie design avoids the distributed-state headache a replicated approach would create, and open-sourcing the server lowers the barrier for other time operators to do the same. The remaining gap is clients: NTS only helps if the devices asking for the time can authenticate the answer, which is why Meta is directly asking maintainers of NTP clients on Android and iOS to add support.