Summary

  • Der CURRENT-BoF behandelte MLS-Schlüsselverwaltung für die TLS-1.3-Record-Schicht, ist aber nicht chartered; laut Protokoll von IETF 126 war die Problemstellung noch nicht hinreichend verstanden.
  • Im Zwei-Parteien-Profil sendet der Empfänger nach Anwendung des Commits ein authentisiertes EpochKeyUpdate; der Initiator darf seinen vorgemerkten Zustand erst nach dessen Prüfung aktivieren.
  • Gesendet, lokal installiert, altes Geheimnis gelöscht und Anwendungsdienst in der neuen Epoche sind getrennte Nachweise.

Ein Zeitfenster mit zwei wahren Ansichten

A sendet ConnectionUpdate. B prüft und verarbeitet den Commit, antwortet mit EpochKeyUpdate und nutzt neues Material. Bs Protokoll ist korrekt. A bleibt in Awaiting EpochKeyUpdate und darf den vorgemerkten Zustand erst nach authentisierter Bestätigung übernehmen.

Diese Asymmetrie schützt davor, eine lokale Handlung als Beweis für den entfernten Zustand auszugeben. Gefährlich wird sie, wenn ein Dashboard den Weg als „Rotation abgeschlossen“ verdichtet.

Beide Kerndokumente sind individuelle Internet-Drafts der Revision 01 ohne RFC-Stream. CURRENT bleibt ein nicht chartered BoF. In Wien wurden Problemumfang, Zwei-Parteien-Grenze bei Mehrparteienfällen und mögliche bestehende TLS-Lösungen hinterfragt. Das ist kein angenommener Standard.

PCS verlangt Verarbeitung und Löschung

RFC 9420 sagt: Ein Update Proposal schafft noch keine Post-Compromise Security. Es muss in einen Commit aufgenommen und von Mitgliedern verarbeitet werden. Forward Secrecy hängt zudem davon ab, alte private Schlüssel und verbrauchte Nachrichtenschlüssel zu löschen.

Die Entwürfe exportieren MLS-Geheimnisse an die TLS-Record-Schicht und bewegen die Epoche mit In-Band-Commits. Die authentisierte Bestätigung belegt Kenntnis des neuen Zustands. Sie belegt nicht automatisch, dass jede alte Kopie gelöscht, der Angreifer ausgesperrt, die Identität gültig oder der Anwendungsdienst intakt ist.

„PCS-fähig“ bezeichnet eine Eigenschaft; es datiert nicht das Ende einer Exposition.

Kollision und Wiederaufnahme hinterlassen Herkunft

Senden beide Seiten gleichzeitig Updates, entscheidet die ursprüngliche Rolle: Eine Seite ignoriert den konkurrierenden Commit, die andere verwirft ihren vorgemerkten und verarbeitet den des Peers. Bei Wiederaufnahme kann ein ausstehender Commit erneut übertragen werden; ein bereits angewandter darf nicht doppelt wirken. Die Erkennung der Unterbrechung liegt außerhalb des Profils.

Nur die End-Epoche zu speichern verwischt normalen Beleg, Kollision, Wiederholung und Wiederaufnahme. Dann ist auch die Dauer alter Schlüssel nicht rekonstruierbar.

Acht Belege

Lu Hengs Minimum Initial Specification begrenzt die gemeinsame Schicht auf deterministische Nachrichten und Übergänge. Running-Code Primacy priorisiert den tatsächlich geprüften, installierten und gelöschten Zustand. Zu trennen sind Erstellung, Versand, entfernte Authentisierung, entfernte Anwendung, Rückbestätigung, lokale Installation, Löschung und der erste authentisierte Anwendungsdatensatz der neuen Epoche.

Der Entwurf selbst bleibt offen: vollständige Sicherheitsanalyse, Protokolltrennung und Teile des Framings tragen TODOs. Ein BoF eröffnet Arbeit; er bescheinigt kein Ergebnis.

Quellen und Grenzen

Diese Quellen belegen weder chartered WG, IETF-Konsens, angenommenen WG-Draft, RFC, vollständige Analyse, Interoperabilität, Einsatz, gemessene Erholung, produktives PQC, Vorfall noch Dienstergebnis.