Summary

  • RFC 8915 splits Network Time Security into a TLS key-establishment exchange and later NTP packets; the client returns an opaque cookie so the server need not retain a record for that client.
  • Cookie encryption keys, exported C2S and S2C keys, request identifiers, replenishment placeholders and local clock state are separate controls. A single “NTS enabled” flag proves none of them together.
  • Dieter Sibold's co-authorship and current IETF roles document contribution to collective standards work. They do not give him control over time truth, implementations, deployments or operator decisions.

The secure connection has ended. The server has discarded the association. Minutes later a UDP request arrives carrying a sealed object that its sender cannot read. The server opens it, recovers the two keys needed for that exchange, authenticates the packet and answers. No per-client session had to survive in the middle.

That is the most consequential move in RFC 8915. Network Time Security, or NTS, does not keep every time client attached to a permanent TLS tunnel. It lets the client carry a server-created record of the previous establishment. The server can forget the individual while retaining enough shared capability to verify the record when it returns.

The distinction matters far beyond clever cryptography. A large public time service may answer vast numbers of clients. If security requires a durable database row for each one, the protection mechanism becomes a scaling liability and a denial-of-service target. If all state travels with the client, continuity improves—but only if operators remember what the portable record does not prove.

Two conversations, with a deliberate break between them

RFC 8915 defines NTS for NTP's client-server modes as a suite of two protocols. NTS Key Establishment, or NTS-KE, begins on TCP port 4460. The parties conduct a TLS handshake, use the ntske/1 application protocol, negotiate NTPv4 and an authenticated-encryption algorithm, and may identify a different NTP server and port for the next phase.

The TLS exporter derives two keys from the establishment: client-to-server, C2S, and server-to-client, S2C. The NTS-KE server also provides an initial stock of cookies. Then request, response and TLS channel end. RFC 8915 says no per-client state remains on the server side.

The second conversation is ordinary NTP carried over its usual datagram path, augmented with NTS extension fields. The 48-octet NTP header is authenticated rather than encrypted. The client includes a random Unique Identifier, one cookie, and an authenticator generated with the C2S key. The response is authenticated with the S2C key and echoes the identifier.

The break is architectural. TLS performs identity checking, negotiation and key derivation where asymmetric cryptography can be afforded. Routine time packets use lightweight symmetric protection. A busy time server does not need to look up a long-lived TLS session before answering every request.

An operating receipt must preserve both phases and the join between them. It should identify the NTS-KE endpoint and certificate result, negotiated next protocol and AEAD, exporter context and key generation, selected NTP endpoint, cookies issued, and the first successful authenticated NTP exchange. A successful handshake without a usable next-protocol packet is not complete service.

The cookie is a sealed association record, not an identity

The NTS cookie is opaque to the client. It is not a browser cookie, username, certificate or clock sample. Its purpose is to move the storage burden for association state from the server to the client without allowing the client to alter that state.

RFC 8915 offers a suggested format. The server forms plaintext containing the negotiated AEAD identifier, the S2C key and the C2S key. It encrypts that plaintext under a separate server-held cookie-encryption key and returns a tuple containing a key identifier, nonce and ciphertext. When a later request arrives, the key identifier selects the appropriate cookie key; successful decryption restores the association values.

The phrase “stateless server” therefore needs qualification. The NTP service can avoid retaining client-specific records. It still maintains configuration and one or more shared cookie-encryption keys. In a cluster, the NTS-KE and NTP components must have compatible access to those keys. If they do not, a perfectly intact client cookie becomes unusable.

The cookie also does not transfer authority to the client. The client stores bytes it cannot interpret and returns them when asked. It cannot choose a different AEAD or substitute new association keys without invalidating the encryption. The record is portable custody, not delegated control.

This is a practical form of the ledger-versus-gatekeeper distinction. The sealed record preserves a prior establishment across a discontinuity, while the server remains the party able to validate and interpret it. The carrier keeps continuity; it does not become the source of the claim.

Two packet keys and one request witness

C2S and S2C are deliberately different. A key used to authenticate client requests is not reused to authenticate server responses. That directionality prevents a valid object from one flow being silently treated as evidence in the other.

The random Unique Identifier has another job. It is authenticated, sent in the request and copied into the response. The client can determine that the response belongs to a particular request and reject an old response replayed into a new exchange. The identifier is a request witness, not the cookie's decryption key and not a persistent client label.

RFC 8915 protects the client from replay in this client-server profile. It does not make the stateless server remember every request it has already processed. The document treats replayed client requests as harmless to the server, provided the response cannot be turned into an amplification weapon. NTS is consequently specified here only for client mode 3 and server mode 4, not for every NTP operating mode.

These distinctions belong in telemetry. “Authentication failed” should not collapse an unknown cookie-key generation, a bad cookie tag, a bad packet authenticator, a mismatched Unique Identifier and an unacceptable server reply into one counter. Each failure points to a different owner and recovery path.

Empty space in a request pays for new cookies in the response

Cookies are consumed because reuse can make a moving client linkable. The server therefore sends replacements inside authenticated responses. But allowing a tiny request to demand an arbitrarily large bundle would recreate the amplification problem that public NTP services have long faced.

RFC 8915 uses NTS Cookie Placeholder extension fields as prepaid space. A client inserts placeholders into its request; the server can fill corresponding space with fresh cookies. Guidance aims to leave the client with eight unused cookies and advises no more than seven placeholders in one request. If packet size risks fragmentation, the client should request fewer.

The placeholder is not merely padding. It is a resource receipt: response expansion has been budgeted by the request. The server can replenish continuity state without returning a packet materially larger than what arrived at the claimed source address.

A useful dashboard records cookie count, cookie length, placeholders sent, replacements received and packet size. Eight is guidance under the RFC's management model, not a universal proof of health. A client with fewer cookies may have suffered loss, a server may use a different compliant strategy, and an implementation may expose other limits.

Rotation decides when an old portable record stops working

The suggested cookie plaintext has no magic power to survive forever. Its practical validity depends on whether the server still holds the cookie-encryption key named by the record. RFC 8915 recommends rotating those keys, erasing old generations for forward secrecy and retaining a limited number long enough for clients to cross the change without immediately repeating NTS-KE.

If the named key never existed or has been erased, decryption fails and the server returns an NTS negative acknowledgement, NTS NAK. The client must establish fresh keys and cookies. A restart, a cluster-sync error, an aggressive rotation or compromise response can therefore turn cookie inventory into a wave of new TLS work.

That failure boundary is operationally important. The NTP packet service may be healthy while NTS-KE is overloaded. Clients with still-valid cookies can continue; clients whose cookies refer to lost keys cannot. Separating the two services contains some failures but creates a shared-key continuity obligation between them.

Current chrony documentation makes the distinction concrete. Its authdata view reports the key-establishment generation, AEAD type, key length, time since establishment, new attempts, NAK state, cookie count and cookie length as different fields. Its server configuration can persist cookie keys across restart and rotate them while retaining earlier generations. Those are chrony choices, not universal RFC defaults, but they demonstrate what observable running code looks like.

Privacy and resilience ask for opposite cookie behaviour

RFC 8915 tells clients to avoid reusing a cookie when possible. A recurring opaque value can help an observer associate traffic seen before and after a device changes networks. Fresh cookies reduce that additional linkability.

The same document permits reuse when resilience matters more. If NTS-KE is temporarily unavailable and the client has exhausted unused cookies, reuse may preserve authenticated time service rather than force a hard stop. The operator must choose which risk is more important in that context.

Neither choice promises anonymity. The unlinkability objective concerns additional recognizable data in synchronization traffic. It does not prevent the time server itself from observing its clients, remove legacy NTP signals, or make NTS-KE traffic unlinkable. Ordinary NTP header information also remains visible.

The receipt should therefore say whether a cookie was first-use or reused, why reuse was permitted, whether the client changed networks, how long NTS-KE had been unavailable and when the fresh-cookie stock recovered. A privacy policy expressed only as “NTS on” misses the decision that actually changes linkability.

Authentication cannot decide whether the time is true

An authenticated response proves a narrower proposition: it was produced by a party holding the expected key and its protected content was not modified. It does not prove that the server's clock is accurate, that its upstream sources are honest, or that the client selected the right source.

RFC 8633 recommends multiple independent and diverse time sources because one authenticated source can still be wrong. RFC 5905's filtering, intersection, clustering and clock discipline remain separate from NTS. The client ultimately decides whether a measurement is usable and how its local oscillator should move.

Delay attacks expose the boundary sharply. An on-path adversary may delay a valid request or response asymmetrically without changing a protected byte. NTP's offset calculation then sees distorted path timing. Authentication succeeds while the measured time shifts. Multiple paths or sources and distance limits can reduce exposure, but NTS cannot cryptographically erase network latency.

The initial certificate check contains a smaller paradox. TLS certificates have validity dates, while the client may seek NTS precisely because its clock is not trustworthy. RFC 8915 offers mitigations—persistent last-known time, strict policy where a battery-backed clock exists, multiple sources and comparison between the new time and certificate interval—but calls no method perfect.

This is why an NTS receipt must continue past packet authentication. It needs measured offset and round-trip delay, root distance, selected and rejected sources, agreement set, system-clock status and adjustment applied. A green tag is one input to time discipline, not its conclusion.

Dieter Sibold's record is participation with boundaries

RFC 8915 was published in September 2020 with five authors: Daniel Fox Franke, Dieter Sibold, Kristof Teichel, Marcus Dansarie and Ragnar Sundblad. It is an IETF Standards Track document and a product of public review and IETF consensus. Naming Sibold helps trace responsibility for a contribution; it does not turn a collective standard into a personal command.

The current IETF Datatracker lists Sibold as a chair of the Network Time Protocols working group and a reviewer in the Internet Area Directorate. It lists RFC 8633 and RFC 8915 under his record. The working-group page names him alongside Karen O'Donoghue and describes continuing work on NTP, NTS, NTPv5, delay resistance and related time protocols.

PTB's current institutional imprint identifies Dr. Dieter Sibold as its information security officer. An official PTB notice about secure computer-time synchronization names him as a contact and cites RFC 8915. These records connect standards work to a national metrology institution whose responsibilities make reliable time operational rather than decorative.

The records are time-bounded. They do not prove that Sibold solely invented NTS, controls IETF consensus, sets chrony's behaviour, operates every PTB time service or decides how any network deploys the protocol. The same discipline applied to an encrypted cookie applies to a biography: contribution is not ownership, and an attributable role is not unlimited authority.

Build one receipt from establishment to clock adjustment

The first part of the record belongs to NTS-KE: endpoint, certificate chain and validation policy, TLS and ALPN outcome, negotiated next protocol and AEAD, exporter context, key generation, selected NTP endpoint, cookies issued and establishment time. Secret key bytes must not be logged; stable generation identifiers and protected evidence are enough.

The second part belongs to cookie continuity: cookie-key identifier, server key generation, issue and first-use times where observable, reuse status, placeholder count, remaining inventory, NAK result, rotation event and recovery establishment. It should show whether a cluster member could decrypt a cookie without exposing its content.

The third part belongs to each NTP exchange: request Unique Identifier or a safe hash, packet direction, authentication result, response correlation, offset, delay, dispersion and rejection reason. The final part belongs to the clock: candidate sources, selection result, system-clock state, correction applied and post-adjustment health.

Joining these stages prevents an attractive false conclusion. A service can authenticate a packet and still choose bad time. It can hold accurate time and still lose cookie continuity. It can complete TLS and fail the first protected NTP request. It can preserve cookies through a restart while using stale or correlated sources.

Running-code primacy means testing those transitions rather than accepting a configuration label. The durable claim is not “NTS is enabled.” It is that the identity check, portable state, packet witness, source decision and clock change can each be reconstructed—and that no one of them silently claims the authority of all the others.

Sources