Summary

  • A valid Roughtime response proves who signed a bounded time claim after receiving a particular request. It explicitly does not prove that the claimed time is correct.
  • A chained malfeasance report can prove response order and that at least one server was wrong. It does not identify the culprit, accept the report, maintain the trust list or revoke a key.

Three clocks answer in sequence. Their signatures verify. Each response is tied to the request before it, and the later request is tied to the earlier response. Yet the intervals cannot all fit the order in which the evidence arrived. Something is wrong, and the packet chain can prove it.

What the chain cannot do is point to one clock and say: this one lied.

That distinction is the most consequential feature of revision 19 of Roughtime. The document is an active NTP Working Group Internet-Draft in the IETF stream, intended for Experimental publication and already in the RFC Editor process. It is not yet an RFC. The visible change from revision 18 is mostly editorial, so the news is not a newly invented attribution rule. It is the current specification's unusually honest boundary between detecting a contradiction and assigning blame.

One signature, one bounded claim

A Roughtime request contains a nonce. The server includes a request-derived leaf in a Merkle tree and signs a response containing the root, a midpoint called MIDP and a radius called RADI. A temporary Ed25519 key signs that response; the server's long-term key signs the delegation that names the temporary key and bounds it with MINT and MAXT.

The client checks the delegation signature, the temporary-key signature, the midpoint's place inside the delegation interval and the inclusion of its request in the Merkle tree. Passing those checks makes the response valid.

The draft then draws the line that many systems blur: validity does not prove the timestamp is correct. It proves that the server guarantees it signed that timestamp and computed the signature within (MIDP-RADI, MIDP+RADI). A narrow radius is still the server's assertion about its clock. Cryptography protects the statement; it does not manufacture truth behind the statement.

The chain closes one question

Multi-server mode begins with a configured list and at least three operational servers not run by the same parties. The client queries them sequentially, then repeats the order. After an initial random nonce, each later nonce is derived from the previous full response plus fresh randomness. A server therefore signs into a chain that carries the history before it.

For each ordered pair, the client asks whether the earlier interval can precede the later one. If the validity checks pass but the intervals violate causal ordering, the draft calls the result malfeasance. The report preserves the expected public keys, random values, requests and responses in receipt order.

That is strong evidence. It can demonstrate that at least one server sent the wrong time. It makes denial harder because the contradictory claims and their order survive outside the client that observed them.

But the logical result is disjunctive: one or more members of the set are wrong. Without another trusted reference, the contradiction does not reveal which member. Two honest clocks can expose a dishonest third; two colluding clocks can also make an honest third look isolated. Independence of operation, diversity of time sources and the provenance of the server list therefore remain part of the security argument.

The missing institution is deliberate

The draft specifies a common server-list format and a JSON report format. It does not specify who earns a place on the list, who removes a server, which report is accepted, how conflicting reports are joined, what standard of review applies or what appeal follows revocation. It offers a forum of human observers as one simple possibility, not as a protocol result.

This is not a defect that should be hidden behind automation. The document itself calls list maintenance and violation adjudication essential for security while leaving them outside the wire protocol. The evidence layer can remain narrow precisely because consequence authority is separate.

A production operator should preserve that separation in data. Store the signed interval and raw response; signature and inclusion validity; the exact contradictory pair and chain; the server-list identity and version; the report's review disposition; and any later revocation, client refresh or remediation. “Report submitted,” “report accepted,” “server attributed,” “key revoked” and “downstream systems repaired” are not synonyms.

The same caution applies to keys. Compromise of a delegated private key remains dangerous even after MAXT, because an attacker can backdate a forged statement into the key's former validity interval. Expiry limits what a verifier should accept as current; it does not erase the evidentiary consequences of later key compromise.

Roughtime can help a device with no trusted clock obtain a rough interval for certificate bootstrapping. It can bound NTP or PTP observations. It does not become a legal timestamp, a transaction sequencer, proof of device integrity or evidence that real-world work occurred.