Summary

  • RFC 9523 describes Khronos, an NTP watchdog that randomly samples a large server pool, removes offset extremes and can take control of the local clock.
  • Its protection is conditional on the sampled-adversary model. A passing estimate does not prove independent operators, paths, implementations or upstream time references behind the selected addresses.
  • Trustworthy time needs joined receipts for pool composition, independence, selection, raw samples, the filtered estimate, clock action and an external reference.

Imagine a time dashboard showing fifteen healthy responses. The offsets cluster tightly. Khronos discards the upper and lower thirds, the surviving range fits its bound, and the resulting estimate stays below the intervention threshold. Every algorithmic check is green.

Now imagine that nine of those addresses, although visibly distinct, ultimately inherit one faulty upstream reference. This is not a reported incident or an allegation about the NTP Pool Project. It is a control hypothesis. It asks whether the green result proves what an executive may assume it proves.

It does not. It proves that a particular calculation succeeded over a particular set of observations. RFC 9523 makes that calculation substantially harder for an attacker to manipulate. It does not turn the population supplied to the calculation into an independently governed census of UTC.

What Khronos actually controls

Khronos is a companion to an NTPv4 client, not a new wire protocol. Under normal conditions it runs as a passive watchdog. It periodically calculates its own time offset while the ordinary NTP client retains the precision advantages of its usual discipline. When the Khronos offset exceeds a predefined threshold, H, the watchdog treats that divergence as an attack indication and updates the local clock itself.

The design widens the observation surface without querying hundreds of servers at every poll. A local pool contains n candidates—500 in the RFC's representative configuration. During a Khronos interval, the client selects m servers uniformly at random—15 in that example—and requests time samples. Secure randomness is mandatory because predictable selection would let an adversary concentrate effort on the next draw.

Non-responses are removed. If too few samples survive, the client draws again. From a sufficient set, Khronos discards the lowest third and highest third of offset values. It then tests whether the remaining offsets fit within a defined range and whether their average is consistent with the accumulated inter-poll movement. A failed test causes resampling; after K unsuccessful attempts, the client enters panic mode.

These are meaningful controls. They separate ordinary NTP selection from a broader, adversary-aware estimate. They also make the security claim inspectable: the pool n, sample size m, threshold H, resampling limit K, raw samples, discarded thirds and surviving range can all be recorded.

A probability statement is not a provenance statement

RFC 9523 says Khronos prevents clock shifting when compromised time samples remain below two thirds. It also gives an illustrative analysis: with a 500-server pool, one seventh controlled by an attacker, fifteen queries per poll and a target shift above 100 milliseconds, the expected time for a successful attack exceeds twenty years.

The qualifying words matter. The result is an expectation under named parameters and assumptions. It is not a warranty for every client, every pool refresh or every dependency structure.

An address count is not an operator count. An operator count is not a network-path count. Different paths can still terminate in one implementation family or inherit one upstream reference. Geographic dispersion can reduce some correlated risks while leaving administration, hosting, software supply or reference-clock lineage concentrated. The algorithm cannot infer those relationships from offset values alone.

This is the distinction between robustness and provenance. Trimming extremes answers: “Can a bounded minority drag this sample away?” Pool provenance asks: “What constitutes an independent member of the population, and which failures could move several members together?” Both questions are necessary; neither substitutes for the other.

Calibration is part of the security boundary

Khronos builds its local pool during calibration. The RFC describes repeated DNS queries to NTP pools, combining returned addresses into a large set and refreshing it periodically. It recommends general pools rather than limiting discovery to a client's state or region, and it permits manual choices or other sources such as public time services.

That design makes discovery operationally feasible. It also means that pool DNS answers, deduplication, refresh timing and manual additions determine the population before the random draw begins. Secure randomness can protect selection from an eligible set; it cannot prove that the eligible set was diverse, current or free from correlated dependency.

A useful calibration receipt should therefore record the names queried, time and resolver path, every returned address, deduplication rule, manual additions, removals and expiry. A separate independence receipt should map each retained server, as far as the evidence allows, to its operator, ASN and network path, software family, hosting environment and upstream reference lineage. Unknown is a legitimate value. Treating unknown as independent is not.

The NTP Pool Project is explicit that it is a volunteer service with operational requirements and monitoring. Its DNS service is valuable infrastructure. Pool membership, however, is not a certificate that every returned IP has unique ownership or a separately governed source of UTC. That is not a defect in the pool's purpose; it is a reason not to assign a discovery service an assurance claim it never made.

Authentication protects a channel, not the clock behind it

Network Time Security can authenticate exchanges and make on-path manipulation harder. RFC 9523 correctly notes that it offers little protection when the time server itself is compromised. The same boundary applies to correlated error without malicious intent: a cryptographically authentic server can faithfully report time inherited from a bad upstream reference.

The operational record should therefore retain two different facts. The first is channel evidence: which endpoint responded, whether NTS authenticated it, and which request and response were paired. The second is reference evidence: stratum, reference identifier where meaningful, observed path, upstream lineage where known and comparison against a separately governed source. Authenticity answers who spoke on the protected channel. It does not make the speaker's clock correct.

Seven receipts turn a green estimate into an auditable claim

The pool-composition receipt captures calibration inputs and the eligible population. The independence receipt captures control and shared-dependency evidence. The selection receipt records the secure-random implementation, seed provenance, parameters n and m, and exact selected members.

The sample receipt preserves every request, response, delay, offset, stratum, leap state and non-response. The estimate receipt shows which thirds were removed, which members survived, the spread and inter-poll tests, resampling count and final Khronos offset. The clock-action receipt records H and K, passive or active state, the applied clock change and any holdover or rollback decision.

Finally, the external-reference receipt compares the result with a separately governed reference and carries its own uncertainty. This last receipt is not an oracle. It prevents a single sampling ecosystem from both producing and certifying its conclusion.

Heng Lu's distinction between minimum specification, running code and observed reality is practical here. RFC 9523 supplies a portable mechanism. Implementers choose entropy and filtering code. Operators shape calibration and thresholds. The clock consumer experiences the result. Keeping those layers joined without declaring them identical is the basis of accountable automation.

What the evidence does not establish

The closed sources provide no deployment census, vendor matrix, named incident or measured global failure rate for Khronos. The shared-reference opening is illustrative. A threshold crossing may be consistent with attack, but it does not uniquely diagnose one; configuration error, path change or reference divergence may also produce a discrepancy.

Nor does a passing estimate prove UTC. The precise claim is narrower and still valuable: under the recorded parameters and observed samples, the Khronos filter produced an estimate that satisfied its conditions. Any stronger statement needs the additional receipts.

Sources