Zusammenfassung

  • KeyUpdate nach RFC 9846 bewegt das Anwendungsverkehrsgeheimnis genau einer Senderichtung vorwärts. Die Übergangsnachricht ist noch mit dem bisherigen Schlüssel geschützt; spätere Records des Senders verwenden die nächste Generation.
  • update_requested verpflichtet gewöhnlich zu einer Gegenaktualisierung, übergibt dem Peer aber nicht die Verbindung. Richtungen bleiben unabhängig, gekreuzte Wünsche können beide Ketten zweimal fortschreiben, stille Wünsche lassen sich zusammenfassen und lokale Grenzen haben Vorrang.
  • Nachweise müssen Terminierung, tatsächliche Aussendung, Annahme durch den Peer und erfolgreiche neue Anwendungsdaten auseinanderhalten. Selbst alle vier belegen weder die Löschung des alten Geheimnisses noch eine neue Identitätsprüfung oder fachliche Autorisierung.

Der letzte Record der alten Generation

Bei einer langlebigen TLS-Verbindung beschließt der Server, seine Sendeschlüssel zu erneuern. Zugleich bittet er den Client um dasselbe. Eine einzige KeyUpdate-Nachricht trägt diese Absicht, doch auf dem Draht existiert kein gemeinsamer Schalter für beide Verkehrsrichtungen.

Der Server verschlüsselt die Nachricht mit dem Schlüssel, den er gerade verlässt. Danach schützt er seine weiteren Records mit dem nächsten Servergeheimnis. Der Client muss die alte Brücke authentisieren, bevor er seine Empfangskette fortschreibt. Seine Antwort wird wiederum unter seinem bisherigen Sendeschlüssel übertragen; erst die anschließenden Client-Records gehören zur nächsten Generation.

Eine Kennzahl „TLS-Schlüsselversion“ macht daraus fälschlich einen atomaren Zustand. In Wirklichkeit besitzen Sende- und Empfangsrichtung getrennte Geheimnisse, Sequenzen und Warteschlangen. Gerade bei gekreuzten Wünschen oder ausgelagertem Record-Schutz entscheidet diese Trennung über die Diagnose.

RFC 9846 ist die heutige Norm

RFC 9846 löste RFC 8446 im Jahr 2026 ab, ohne die TLS-1.3-Drahtkompatibilität zu brechen. KeyUpdate bleibt Handshake-Typ 24 und kennt nur update_not_requested(0) sowie update_requested(1).

Vor Finished ist die Nachricht unzulässig und führt zu unexpected_message; ein anderer Wert führt zu illegal_parameter. KeyUpdate muss an der Record-Grenze vor dem Schlüsselwechsel enden. Der Empfänger darf die nächste Generation erst akzeptieren, nachdem die unter dem alten Schlüssel geschützte Übergangsnachricht authentisiert wurde. Sonst wird aus einer protokollierten Entscheidung eine Vermutung mit Truncation-Risiko.

Das nächste Verkehrsgeheimnis entsteht über HKDF-Expand-Label mit dem Label traffic upd; daraus folgen Schlüssel und IV. Für den Sender gilt eine maximale Epoche von 2^48-1. Ein Empfänger darf diese Grenze nicht stellvertretend erzwingen, weil eine spätere Spezifikation die Senderregel ändern könnte.

Verbindlichkeit ohne Fernsteuerung

Bei Wert null kündigt der Sender nur seinen eigenen Wechsel an. Bei Wert eins muss der Empfänger normalerweise vor seinen nächsten Application Data eine KeyUpdate ohne erneuten Wunsch senden. Diese Pflicht ist genauer als ein unverbindlicher Hinweis, aber schmaler als Hoheit über lokale Ressourcen.

Ein Endpunkt darf keinen weiteren angeforderten Wechsel losschicken, solange eine Peer-KeyUpdate aussteht. Mehrere Wünsche, die während des Schweigens eingehen, können durch einen Wechsel erfüllt werden. Kreuzen sich zwei eigenständig angeforderte Updates, antworten beide Seiten dennoch; jede Richtung kann dadurch zwei Generationen weitergehen.

Würde die Antwort die lokale Epochenobergrenze überschreiten, darf der Sender nicht aktualisieren und sollte das Request-Flag ignorieren. Später kann ein AEAD-Nutzungslimit die Beendigung erzwingen. Ein gültiger Peer-Wunsch begründet also keinen unbegrenzten Anspruch auf CPU, neue Geheimnisse oder Lebensdauer der Verbindung.

Die Kette reicht nicht in den fremden Speicher

Ohne das aktuelle Geheimnis kann ein Beobachter die nächste Generation nicht allein aus dem Netzwerkverkehr herleiten. Dieser Ableitungszusammenhang belegt Kontinuität. Nach der Berechnung soll die Implementierung das vorherige Geheimnis und dessen Schlüssel löschen. Ob das geschieht, ist jedoch eine lokale Eigenschaft.

Ein erfolgreicher neuer Record sieht weder den Heap des Peers noch ein HSM-Fach, eine Kernel-Offload-Tabelle, einen Crash-Dump oder eine Sicherungskopie. Wer aus der Antwort „alte Schlüssel vernichtet“ ableitet, ersetzt eine Interoperabilitätsaussage durch eine unbelegte Attestierung.

Auch die Identität bleibt bestehen. KeyUpdate fordert kein neues Serverzertifikat an, wiederholt keine Namensprüfung, ändert keinen authentisierten Client und genehmigt keinen Anwendungsvorgang. Ein frischer Record-Schlüssel kann eine unzulässige fachliche Handlung genauso zuverlässig schützen wie sein Vorgänger.

Laufender Code zeigt die verborgenen Zeitpunkte

OpenSSL lässt SSL_key_update() erst nach dem anfänglichen Handshake zu. Ein erfolgreicher Aufruf plant das Update; spätere I/O oder ein ausdrücklicher Handshake-Antrieb bringt es auf den Draht. Die Anwendung muss ausstehende Writes koordinieren. Rückkehrzeitpunkt und Sendezeitpunkt sind daher verschiedene Belege.

GnuTLS macht die Richtung sichtbar: Standardmäßig wird lokal gesendet; GNUTLS_KU_PEER fordert zusätzlich den Peer auf. Der Vorgang kann nichtblockierende Ergebnisse wie ein Record-Write liefern. Das Handbuch trennt Rekeying ausdrücklich von Reauthentisierung.

rustls stellt refresh_traffic_keys() bereit und verfolgt im Normalbetrieb Vertraulichkeitsgrenzen der Cipher Suite. Wird Record-Schutz über die Kernel-Schnittstelle ausgelagert, muss die Anwendung Zählung, Erneuerung und Abbruch verantworten. Die Abstraktionsgrenze verschiebt sich, nicht die Rechenschaftspflicht.

Drei Transporte, drei Beweisobjekte

QUIC nutzt TLS 1.3 für den Handshake, verbietet aber TLS-KeyUpdate-Nachrichten. QUIC Version 1 erneuert Packet Protection über das Key-Phase-Bit, Bestätigungsfolgen und die Ableitung quic ku. Ein TLS-KeyUpdate-Zähler meldet dort korrekterweise nichts.

DTLS 1.3 behält KeyUpdate in einer Welt von Verlust und Umordnung. Es verwendet Epochen und Acknowledgements und hält ältere Empfangsschlüssel für verspätete Datagramme vor. Eine Antwort kann die Anfrage kreuzen und ist deshalb nicht automatisch deren Bestätigung.

„TLS-Rekey“ ist als Betriebsetikett bequem, als Nachweis aber zu grob. Stream-TLS verlangt die geordnete alte Brücke, DTLS einen bestätigten Epochenwechsel und QUIC eine Paket-Schlüsselphase. Gemeinsames Ziel bedeutet nicht gemeinsame Evidenz.

Ein Ledger ohne Schlüsselmaterial

Ein belastbarer Datensatz enthält Verbindungsreferenz, Rolle, Transport, Version, Richtung sowie alte und neue Generation. Er nennt den Auslöser — Richtlinie, Bibliotheksgrenze, Bediener oder Peer —, den Request-Wert, den Outstanding-Zustand, die authentisierte alte Brücke, Record-Grenze, erste erfolgreiche neue Anwendungsdaten, Zusammenfassungen, Kreuzungen, Ratenentscheidung und terminalen Alert.

Vier Meilensteine bleiben getrennt: geplant, gesendet, akzeptiert und mit Anwendungsdaten bewährt. Der Nachweis zur Speicherlöschung gehört in einen eigenen lokal kontrollierten Assurance-Datensatz. Packet Capture allein genügt nicht, weil TLS 1.3 KeyUpdate verschlüsselt; kontrollierte Tests können Callbacks und Zähler korrelieren, ohne Schlüsselmaterial in die Produktionsbeobachtung zu kopieren.

Quellen