Zusammenfassung

  • Roughtime Revision 19 beschreibt ein für Experimental vorgesehenes Protokoll. Verkettete signierte Antworten können beweisen, dass mindestens ein Server eine Zeit gemeldet hat, die mit der kausalen Reihenfolge unvereinbar ist. Nicht jede Kette identifiziert den einzelnen fehlerhaften Schlüssel.
  • Der Entwurf legt Formate für vertrauenswürdige Serverlisten und Fehlverhaltensmeldungen fest. Annahme, Beurteilung, Ausschluss sowie Pflege und Verteilung der Listen bleiben außerhalb seines Umfangs, obwohl der Text diese Verfahren als sicherheitswesentlich bezeichnet.
  • Ein portabler Vertrauensentzug-Beleg sollte Berichtshash, Grenzen der Zuordnung, befugte Prüfung, Entscheidung, signierten Listenübergang, Verteilung, Client-Übernahme und Korrektur verbinden. Das ist ein Vorschlag von Daniel Kade, keine IETF-Anforderung.

Eine echte Signatur kann eine falsche Uhrzeit tragen

Ein Gerät, das lange ausgeschaltet war, kennt womöglich nicht einmal das Jahr genau genug, um ein Zertifikat zu prüfen. Sichere Zeitsynchronisation kann ihrerseits die vorherige Prüfung eines Zertifikats verlangen. Roughtime begegnet diesem Kreislauf mit einem authentisierten groben Zeitintervall und mit extern prüfbarer Evidenz, wenn ausgewählte Quellen einander widersprechen.

Der aktuelle Text ist draft-ietf-ntp-roughtime-19, veröffentlicht am 17. März 2026 mit angestrebtem Status Experimental. Die IESG genehmigte das Dokument am selben Tag. Im Datatracker steht es inzwischen in der RFC-Editor-Warteschlange; am 4. September wechselte der Produktionsstatus zu In Progress (Second Edit). Bis zur tatsächlichen Veröffentlichung bleibt Revision 19 ein Internet-Draft. Ein RFC-Status oder eine Nummer werden hier nicht vorweggenommen.

Zunächst sendet der Client einen frischen Nonce. Der Server liefert Mittelpunkt und Radius eines Intervalls, in dem die wirkliche Zeit seiner Aussage nach liegt. Die Signatur umfasst eine Merkle-Tree-Bindung an die Anfrage. Dadurch lässt sich prüfen, dass der Inhaber eines langlebigen Schlüssels nach Erhalt dieses Nonce geantwortet hat.

Authentisiert ist die Aussage, nicht die Richtigkeit der Uhr. Ein ordnungsgemäßer Schlüssel kann eine fehlerhafte Konfiguration, eine kompromittierte Maschine, eine falsche Referenz oder eine absichtliche Täuschung signieren. Im Mehrservermodus fließt deshalb Material einer Antwort in die nächste Anfrage ein. Die Intervalle werden an die tatsächliche Reihenfolge der Vorgänge gebunden.

Passen sie nicht in diese Reihenfolge, kann der Client Anfragen, Antworten, Schlüssel und Zufallsmaterial aufbewahren. Ein anderer Prüfer kann den Widerspruch reproduzieren. Das Ergebnis ist stark, aber begrenzt: Mindestens eine Zeitantwort war falsch. Je nach Aufbau der Kette ist nicht feststellbar, welche.

„Dieser Schlüssel hat geantwortet“, „diese Antworten sind unvereinbar“ und „dieser Schlüssel muss aus der Liste“ sind drei verschiedene Feststellungen. Der letzte Schritt braucht eine Entscheidungsbefugnis, die nicht in der Signatur steckt.

Der Entwurf markiert die Grenze selbst

Revision 19 erklärt offen, dass Betriebserfahrung mit Diensten nötig ist, die vertrauenswürdige Serverlisten pflegen und verteilen sowie Meldungen bearbeiten. Der Entwurf beschränkt sich auf das Drahtprotokoll und Datenformate. Er bestimmt weder Listenpolitik noch Verteilungs- und Prüfverfahren.

Für einen Ausschluss sei ein zusätzlicher Review- und Impeachment-Prozess erforderlich; seine Definition liege außerhalb des Umfangs. Auch Regeln zur Annahme oder Ablehnung einzelner Meldungen sind nicht festgelegt. Die Sicherheitsbetrachtung nennt Infrastruktur und Verfahren für Listenpflege und Beurteilung von Verstößen ausdrücklich unverzichtbar.

Diese Trennung ist mehr als eine offene Implementierungsaufgabe. Signaturen und Nonce-Verbindungen lassen sich deterministisch prüfen. Für eine Zuordnung müssen gemeinsame Zeitquellen, Schlüsselverwahrung, Radius, Schaltsekunden, Softwarefehler und externe Betriebsdaten untersucht werden. Eine Maßnahme verlangt zusätzlich Verhältnismäßigkeit, Dauer, Unabhängigkeit und Kontinuität.

Schon das Wort malfeasance kann Absicht suggerieren. Die Evidenz zeigt zunächst Inkonsistenz. Ursache können Irrtum, Kompromittierung oder Täuschung sein. Der erste belastbare Zustand lautet daher Widerspruch bestätigt, Zuordnung offen.

Signaturfehler oder andere Protokollfehler dürfen nach dem Entwurf allein keine solche Meldung auslösen. Das hält den Kanal semantisch sauber: Er trägt Kausalitätswidersprüche, nicht beliebige Störungsmeldungen.

Die Serverliste ist ausführbare Vertrauenspolitik

Langlebige öffentliche Serverschlüssel sind die Vertrauenswurzeln von Roughtime. Der Client benötigt mindestens drei funktionsfähige Server unter unterschiedlichen Betreibern und soll seine Einschätzung ihrer Vertrauenswürdigkeit aktualisieren.

Das gemeinsame JSON-Format kann Namen, Adressen, Versionen und Schlüssel enthalten, außerdem Quelllisten und eine HTTPS-Adresse für Meldungen. Die Nutzung ist optional; ein Client darf andere Konfigurationen verwenden.

Damit wird aus einem gemeinsamen Format kein weltweiter Listenhalter. Ein Betriebssystemanbieter, ein Unternehmen und eine Forschungsgemeinschaft können verschiedene Listen pflegen. Clients dürfen Aktualisierungen übernehmen, verzögern, ablehnen oder abzweigen.

Trotzdem ist Listenpflege eine Machtposition. Ein Schlüssel in der Liste darf künftige Messungen mitprägen. Seine Entfernung schließt ihn bei übernehmenden Clients aus. Zu spätes Handeln verlängert Exposition; vorschnelles Handeln kann Vielfalt zerstören. Eine stille Wiederaufnahme löscht institutionelles Gedächtnis.

Der Listenhalter übt eine begrenzte Delegation seiner Nutzer aus, keine allgemeine Gerichtsbarkeit über den Server. Wirkung entsteht erst, wenn eine neue Liste signiert, verteilt, vom Client geprüft und lokal angenommen wird.

Überlastschutz darf den Nachweis nicht vernichten

Bei erkannter Inkonsistenz soll der Client nach Möglichkeit einen Bericht erzeugen, den Nutzer warnen und erneut messen. Enthält die Liste eine Meldestelle, erfolgt die Übermittlung per HTTPS.

Der Ausfall eines bekannten Servers könnte viele Clients gleichzeitig auslösen. Daher verlangt der Entwurf exponentielles Backoff. Die Empfangsstelle wird geschützt; der Bericht muss während der Wartezeit dennoch unverändert erhalten bleiben.

Eine belastbare Annahmestelle bildet einen Inhaltshash, bestätigt dauerhafte Verwahrung und trennt identische Wiederholungen von unterschiedlichen Ketten. Wiederholte Zustellung ist keine zusätzliche Stimme. Andererseits dürfen unterschiedliche Beobachtungswege nicht allein wegen desselben Schlüssels verschmolzen werden. Der Eingangsbeleg sagt „gespeichert“, nicht „widerrufen“.

Auch Datenschutz folgt dem Beweiszweck. Nachrichten und Schlüssel sind nötig; eine dauerhafte Geräteidentität ist es meist nicht. Rechenschaft darf nicht beiläufig ein Register der Beobachter schaffen.

Zuordnung ist kein binärer Automat

Zwei stimmige Zeugen können ein unmögliches mittleres Intervall isolieren. In einer anderen Kette stehen nur zwei unvereinbare Aussagen gegenüber. Server können Betreiber, Upstream-Uhr oder Softwarefehler teilen. Ein Schlüssel kann gestohlen sein. Eine Minderheitsantwort kann als einzige richtig sein, wenn die Mehrheit korreliert versagt.

Die Prüfung wiederholt jede Signatur, jede Nonce-Verbindung, jedes Intervall sowie Radius- und Schaltsekundenbehandlung. Danach gibt sie einen präzisen Status aus: einzelner Schlüssel identifiziert, Kandidatenmenge oder nicht zugeordneter Widerspruch.

Betriebstelmetrie und unabhängige Zeitreferenzen können helfen, besitzen aber andere Provenienz. Ihre Aussage wird nicht allein durch Beilage zum kryptografischen Bericht mathematisch.

Ein dauerhafter automatischer Ausschluss nach dem ersten gültigen Bericht täuscht Zuordnungsgewissheit vor. Auf absolute Gewissheit zu warten, entwertet die Warnung. Eine befristete Quarantäne oder Abwertung, anschließende Untersuchung und eine begründete Entscheidung mit Ablaufdatum bilden den verantwortbaren Mittelweg.

NTS und Khronos sichern andere Flächen

RFC 8915 definiert Network Time Security mit TLS und authentisierter Verschlüsselung für NTP. Der Client kann Herkunft, Integrität und Wiedergabeschutz prüfen. NTS garantiert nicht, dass die authentisierte Serveruhr richtig geht.

Roughtime kann einem Gerät ohne brauchbare Uhr das Intervall verschaffen, das es zur Prüfung des NTS-KE-Zertifikats braucht. Zugleich liefert es externe Evidenz widersprüchlicher signierter Quellen. Die Funktionen ergänzen sich.

Khronos aus RFC 9523 stärkt Auswahl und Filterung gegen Zeitverschiebungsangriffe. Es schützt die lokale Auswahl. Roughtime betont einen für Dritte prüfbaren Widerspruch. Auswahl erzeugt keine vollständige Verantwortungsakte; eine Akte wählt nicht die nächste Vertrauensmenge.

RFC 8633 verlangt mehrere Quellen und Überwachung, RFC 7384 beschreibt Angriffe auf Zeitquellen und Abhängigkeiten anderer Sicherheitsdienste. Keines der Dokumente erzeugt aus Kryptografie eine universelle Ausschlussinstanz.

Der portable Vertrauensentzug-Beleg

Daniel Kade schlägt einen portablen Vertrauensentzug-Beleg für die Übergänge nach der Protokollprüfung vor. Er ist weder neue Roughtime-Nachricht noch zentrales Gericht.

Zuerst fixiert er Berichtshash, vollständige Kette, Prüfsoftware und Version, Ergebnisse aller Signaturen und Nonce-Verbindungen sowie den Hash der vom Client verwendeten Liste. Er erfasst nur den nötigen Erhebungskontext.

Dann nennt er den Zuordnungsstatus, den befugten Prüfer, Interessenkonflikte, externe Evidenz, Grund, Konfidenz und Frist. Verifikation und Urteil bleiben sichtbar getrennt.

Die Maßnahme steht in einem eigenen Abschnitt: Quarantäne, Gewichtung, Entfernung oder Wiederaufnahme. Hashes der alten und neuen Liste, Sequenz, Signierer und Wirksamkeit bilden einen prüfbaren Übergang. Vorläufiges Handeln läuft ohne begründete Erneuerung ab.

Auch Verteilung erhält Evidenz. Veröffentlichungsstellen und Transparenzarchiv zeigen, was angeboten wurde. Aggregierte Client-Daten zeigen installierte Hashes, Verzögerung und lokale Ablehnungsgründe. Veröffentlichung wird nicht als Übernahme ausgegeben.

Schließlich bleibt Korrektur möglich. Der Betreiber kann Schlüsselkompromittierung zeigen, eine Referenz reparieren, den Schlüssel wechseln oder die Zuordnung anfechten. Eine Wiederaufnahme ergänzt den Verlauf um einen signierten Übergang, statt den alten Bericht zu löschen.

Vertrauen ändert sich im Client. Eine Meldung überschreibt keinen Cache und keine lokale Richtlinie. Nach der Entfernung ist außerdem zu prüfen, ob drei unabhängige Betreiber erreichbar bleiben. Sonst zerstört die Abwehr den sicheren Start.

Roughtime macht einen präzisen Widerspruch schwer bestreitbar. Gute Governance hält Urteil, Veröffentlichung, Übernahme und Korrektur ebenso sichtbar, ohne aus Evidenz eine Herrschaftsbefugnis zu machen.

Quellen