Zusammenfassung

  • Maßgeblich ist inzwischen draft-ietf-tls-extended-key-update-13; Revision 11 ist überholt, und der Text bleibt ein Internet-Draft statt eines verabschiedeten RFC oder eines Einsatznachweises.
  • Request, Response und Finish können neues Schlüsselmaterial einbringen, bezeugen aber weder die lokale Löschung alter Geheimnisse noch den vollständigen Wechsel beider Richtungen.
  • Eine belastbare Erholungsaussage verbindet Aushandlung, Reihenfolge, frische Generierung, Ableitung, Zustandsvernichtung, erste neue Records je Richtung und einen bidirektionalen Anwendungstest.

Beweglicher Entwurf, klare Statusgrenze

Der IETF Datatracker führt Revision 11 als ältere Fassung. Revision 13 wurde am 4. Juli 2026 veröffentlicht und läuft am 5. Januar 2027 aus. Sie zielt auf Proposed Standard, steht bei der IESG aber nur auf „I-D Exists“ und hat weder zuständigen Area Director noch Telechat-Termin.

Revision 13 nennt Subtyp 2 nun key_update_finish, präzisiert den Schutz aller drei EKU-Nachrichten durch die alten Schlüssel und erweitert die Betrachtung aktiver Angreifer. Eine Fähigkeitserklärung muss daher die konkrete Revision und das beobachtete Verhalten nennen. „IETF-standardisiert“ wäre verfrüht.

Drei Grenzen vor dem Austausch

Der Client schlägt Extended_Key_Update über TLS Flags im ClientHello vor. Der Server bestätigt es in EncryptedExtensions nur bei Unterstützung und Aktivierung. Ohne Bestätigung muss eine Anwendung mit PCS-Anforderung einen vollständigen neuen Handshake ausführen.

Nach erfolgreicher Aushandlung ist das klassische KeyUpdate verboten und führt zu unexpected_message. Request und Response müssen dieselbe Gruppe wie der ursprüngliche Handshake nutzen; eine andere Gruppe führt zu illegal_parameter. Code-Unterstützung, Richtlinienfreigabe und Sitzungsvereinbarung sind eigenständige Tatsachen.

Der Wechsel ist richtungsabhängig

Der Initiator sendet key_update_request mit frischem Key Share. Der Responder antwortet mit key_update_response und wechselt anschließend seinen Sendeschlüssel. Der Initiator leitet den neuen Zustand ab, wechselt den Empfang, sendet ein leeres key_update_finish noch unter dem alten Schlüssel und wechselt erst dann den Versand. Der Responder schaltet seinen Empfang erst nach Authentisierung dieses alten Finish um.

Vorübergehend besitzen beide Endpunkte je Richtung unterschiedliche Generationen. Ein einzelnes Feld „Verbindungsschlüsselversion“ verschleiert diesen Zustand. Gekreuzte Requests werden anhand von key_exchange entschieden: Der lexikografisch kleinere Wert verliert, Gleichheit beendet die Verbindung.

Die Ableitung mischt das neue gemeinsame Geheimnis mit einem aus dem vorherigen Main Secret gebundenen Wert und einem Transcript Hash des Handshakes sowie aller EKU-Schritte. Daraus entstehen beide Traffic Secrets, Exporter Secret und Resumption Main Secret. Anders als beim klassischen KeyUpdate ist der Nachfolgezustand nicht nur aus der kompromittierten Kette berechenbar.

Wo Protokollsicht endet

Ein Trace kann neue Shares und kompatible Records zeigen. Er belegt weder einen gesunden Zufallszahlengenerator noch ausbleibende Wiederverwendung, noch die Löschung alter Kopien in Heap, HSM, Kernel-Offload oder Crash-Dump. Der Entwurf empfiehlt die schnellstmögliche Löschung; ein entfernter Peer kann sie nicht attestieren.

Der nützliche Beleg ist deshalb eine datensparsame Verknüpfung: ausgehandelte Revision und Gruppe, nicht geheimer Generationsbezeichner, IDs der drei Nachrichten, Nachfolgegeneration, Löschresultat jeder Speicherschicht und erster unter neuen Schlüsseln akzeptierter Record je Richtung.

Auch der Angreifer muss verschwunden sein. Bei dauerhaftem Endpunktzugriff liest er den neuen Zustand. Ein aktiver Gegner mit den laufenden Traffic Keys kann EKU-Nachrichten ersetzen und seine MitM-Position halten, sofern die zusätzliche Authentisierung aus Abschnitt 11 nicht tatsächlich ausgeführt und erfolgreich geprüft wird. Die Erholung einer Sitzung repariert zudem keinen kompromittierten langfristigen Identitätsschlüssel.

DTLS bringt Epochen, Retransmission, vorübergehende Altzustände und ACKs hinzu. Der Initiator beendet seinen Sendewechsel erst nach der Bestätigung in der neuen Epoche. TLS-Telemetrie kann diesen Nachweis nicht durch Umbenennung liefern.

Quellen