Summary

  • Roughtime revision 19 defines an experimental wire protocol in which chained, signed exchanges can prove that at least one server supplied time inconsistent with causal order. The proof may establish a contradiction without identifying which server is at fault.
  • The draft specifies formats for trusted-server lists and malfeasance reports, but expressly leaves list maintenance, report acceptance, adjudication and impeachment policy outside its scope. Those procedures are essential to security, not implementation detail that cryptography removes.
  • A portable impeachment receipt should join the report hash, attribution limits, authorized review, disposition, old and new signed-list hashes, distribution evidence, client adoption and a correction route. This is Daniel Kade’s governance proposal, not an IETF requirement.

A clock answer can be authentic and wrong

Secure time begins with an awkward dependency. Certificates often need a reasonably correct clock before they can be validated, while a device emerging from long storage may need authenticated infrastructure before it can learn the time. Roughtime is designed to give such a client a rough, authenticated interval and to leave external evidence when trusted servers contradict one another.

The current specification is draft-ietf-ntp-roughtime-19. It was published on 17 March 2026 with Experimental status intended. The IESG approved it that day, and Datatracker now places it in the RFC Editor queue; on 4 September the production status moved to In Progress (Second Edit). Those are consequential process facts, but revision 19 remains an Internet-Draft until publication. It has no RFC number in this evidence package.

At its simplest, a client sends a fresh nonce. A server returns a signed response containing a midpoint and a radius: not a claim to a mathematically exact instant, but an interval within which the server says the real time lies. The response commits to the client’s nonce through a Merkle tree. The signature can therefore show that the holder of a particular long-term key produced the response after seeing that request.

That is authentication, not truth. A perfectly valid signature can cover a badly configured clock, a compromised server or a deliberately false interval. Roughtime’s distinctive step is to let a client chain measurements. Material derived from one response becomes part of the next request, so the signed intervals can be tested against the order in which the exchanges must have occurred.

If the intervals cannot fit that causal order, the client has something stronger than a screenshot or an allegation. It can retain the requests, responses, random material and public keys needed to demonstrate a contradiction. The report is independently checkable. But the logical conclusion is bounded: at least one server sent the wrong time. In many chains, the mathematics alone does not identify which one.

The first governance rule follows directly. A signature attributes a statement to a key. A chained contradiction establishes that the statements cannot all be correct. Neither fact automatically attributes fault to the right participant.

The draft draws its own institutional boundary

Revision 19 is unusually candid about the work left outside the packet. It says operational experience is needed with an ecosystem that maintains and distributes trusted-server lists and processes malfeasance reports. The document deliberately limits itself to the on-wire protocol and the two data formats. It does not define how the list is maintained, how it is distributed or what policies govern it.

The boundary appears again in the protocol overview. For a report to result in impeachment, an additional review and impeachment mechanism is required; defining it is beyond scope. The reporting section says the operational rules for accepting or rejecting a report are beyond scope. The security considerations call infrastructure and procedures for maintaining trusted-server lists and adjudicating violations essential for security.

This is not a defect that can be repaired by adding one more mandatory field to a packet. It is a separation of functions. The wire protocol can make a narrow event verifiable. The ecosystem must decide who receives the evidence, how it is checked, whether it is sufficient, what action follows, how that action is published and when clients adopt it.

Calling the report “malfeasance” can obscure that separation. In ordinary language the word suggests wrongful intent. The evidence may instead expose error, compromise, key misuse, faulty time input or another failure whose cause still needs investigation. The draft’s result is an inconsistency proof, not a finding about motive.

An operator should therefore never turn report validity into automatic condemnation. The correct first state is verified contradiction, attribution pending. That label preserves the strongest fact the cryptography supports without borrowing certainty from the filename.

A server list is a trust program, not a phone book

Roughtime’s long-term public keys are roots of trust. A client needs a list with at least three operational servers that are not run by the same parties. It should refresh its view of which servers remain trustworthy so that knowledge of detected misbehaviour can change future measurements.

The draft defines a common JSON format for that list. Entries can carry names, addresses, versions and long-term public keys. The object may also identify source lists and an HTTPS endpoint for reports. Support for the format is optional; clients may use another configuration mechanism.

That optionality is architecturally important. A format enables portability, but it does not appoint one universal list publisher. An operating-system vendor may curate a list. An enterprise may maintain its own. A research community may publish another. Different clients may weight sources differently or refuse a revision. They can form different trust sets without becoming invalid participants in an imagined global jurisdiction.

List maintenance is nevertheless a power surface. Adding a key invites clients to treat its signed intervals as evidence. Removing a key can exclude a server from future measurements by adopting clients. Delaying a removal can leave clients exposed to a known problem. A silent restoration can erase institutional memory even if the old report remains somewhere else.

The maintainer is therefore more than a distributor of addresses, but less than a sovereign. Its decision has effect only through the clients and organizations that choose its list and adopt its revision. The durable question is not whether a list publisher has “authority over Roughtime.” It is which clients delegated which bounded selection decision to that publisher, under what update and exit conditions.

Evidence must survive the reporting path

When a client detects an inconsistency and it is technically feasible, the draft says it should generate a report, alert the user and take another measurement. If its server list supplies a report URL, the client should send the report there over HTTPS.

The report format retains an ordered sequence of response objects, including the request and response bytes, public key and required random material. That is enough to replay the cryptographic checks. The format does not need to carry a prosecutor’s narrative.

Popular failure creates a different operational hazard. Many clients could discover the same bad server and post evidence at once. The draft therefore requires exponential backoff and recommends bounded retry timing. It also prohibits sending a malfeasance report merely because a signature check or another protocol check failed; the causal inconsistency evidence has a specific meaning.

Backoff protects the receiver, but it creates a queue in which governance can disappear. If clients retain only the next retry time and discard the unique report, evidence can be lost during overload. If the receiving service deduplicates only by server identity, it may collapse different chains and hide the scale or topology of a failure. If it counts every retry as a new incident, it can manufacture apparent consensus.

A defensible receiver should content-address the report, acknowledge durable custody without judging it, group byte-identical evidence and preserve distinct chains. Rate limiting should govern transmission, not truth. A receipt for submission should say “stored” or “already held,” never “server impeached.”

Attribution is a constrained inference

Suppose three servers appear in a chain and the intervals are inconsistent. The first and third may agree with one another while the middle answer is impossible. That pattern can be strong evidence against the middle key, but the review still needs to validate every signature and nonce link, reconstruct permitted interval bounds, inspect leap-second and radius handling and rule out malformed or incomplete capture.

Other cases are less clean. Two answers may conflict with no independent anchor. Several servers may share an operator, upstream clock or software fault. A key may have been compromised while the service owner acted correctly. The list used by the client may itself be stale or tampered with. An apparent outlier can be the sole correct witness in a group of coordinated failures.

Roughtime helps because the evidence is portable and responses carry persistent server identities. It does not abolish the need to state the attribution model. A reviewer should publish whether the evidence identifies one key, leaves a candidate set or proves only an unresolved contradiction. If external evidence—operator telemetry, key-custody records or independent time sources—changes the conclusion, that evidence and its authority need to be named separately.

Automatic revocation at the first valid contradiction would optimize for speed by pretending attribution is free. Refusing ever to act without certainty would optimize for institutional comfort by making the evidence useless. The practical middle is a staged disposition: quarantine or lower weight under bounded conditions, investigate, publish the basis, then remove, restore or retain with an explicit expiry.

NTS protects a different boundary

Network Time Security, standardized in RFC 8915, uses TLS for key establishment and authenticated encryption for NTP exchanges. It gives a client cryptographic assurance that synchronization packets came from the selected server and were not replayed or altered within its stated model.

That assurance is essential. It still cannot make an authenticated server’s clock correct. Roughtime can help a device obtain enough time to validate the NTS key-establishment certificate, and it can expose contradictions between signed time providers. The mechanisms complement one another because they answer different questions.

RFC 9523’s Khronos mechanism offers another comparison. It strengthens NTP server selection and filtering against time-shifting attackers. Roughtime emphasizes externally demonstrable inconsistency. Selection can protect one client without producing a portable accusation; portable evidence can support accountability without selecting the next trusted set.

RFC 8633 already advises multiple time sources and monitoring, while RFC 7384 describes malicious-source threats and the circular dependencies between time and security services. None of these documents makes a list publisher’s institutional choice emerge from cryptography. Operators must preserve the boundary between authentic transport, correct time, evidence of contradiction and authority to change trust.

The portable impeachment receipt

The missing bridge can be designed without centralizing the ecosystem. Call it a portable impeachment receipt. It is not a new Roughtime message. It is an operator-facing record that allows a list provider’s decision and a client’s adoption to be examined independently.

The receipt begins with immutable evidence: the content hash of the malfeasance report, the complete ordered chain, validation software and version, results for every signature and nonce link, and the exact hash of the trusted-server list used by the client. Collection context should be minimized so IP addresses or device identity are not retained unless they materially support analysis.

The next section records attribution. It states whether one key is identified, several keys remain candidates or the contradiction is unresolved. It names the authorized reviewer, declares conflicts of interest, distinguishes protocol validation from external operational evidence and gives the disposition’s reason code, confidence and expiry.

Action is a separate section. If a key is quarantined, removed, reweighted or restored, the receipt records the previous and new list hashes, version or sequence, signer and effective time. A human-readable explanation accompanies rather than replaces those machine-verifiable facts. Temporary action must expire unless renewed on stated evidence.

Distribution then gets its own proof. The receipt identifies publication endpoints, archive or transparency location and the signed list object offered to clients. It does not claim that publication equals adoption. Client populations may report privacy-preserving counts of the old and new hashes, installation lag and rejection reason. An enterprise using a local list can document a different decision without falsifying the public publisher’s record.

Finally, the receipt supplies correction. A server operator can challenge attribution, show key compromise, correct a clock source or rotate a key. Reviewers can withdraw a mistaken disposition without deleting the original. Clients can see a restoration as another signed transition rather than a quiet rewrite of history.

This proposal is Daniel Kade’s editorial design, not normative text in revision 19. Its aim is not to create a global tribunal. It is to prevent four different events—proof, judgment, publication and adoption—from being collapsed into the single word “revoked.”

Local adoption is where trust actually changes

The strongest public disposition has no effect on a device that never receives it. Conversely, a local operator may remove a key before any public list changes. Trust is operational state, not a press release.

That means successful response to proven inconsistency must be measured at the client boundary. Which list hash is installed? When was it fetched? Was its signature checked? Did local policy accept it? Did cached or pinned configuration override it? Are at least three independent operational servers still available after removal? Did the change make secure bootstrap less reliable than the risk it was meant to contain?

The thin-waist principle is useful here. Standardize the evidence and the portable list format. Keep future policy choices with the participants running code. A list provider may recommend; a client may adopt, delay, fork or refuse. Non-adoption is not a moral violation, though an operator remains accountable for the risk it chooses to carry.

Roughtime’s achievement is to make a narrow kind of disagreement hard to deny. Its restraint is to avoid pretending that denial-resistant evidence decides who should be trusted next. A robust ecosystem should preserve both properties.

Sources