Zusammenfassung

  • draft-ietf-tls-tlsflags-18 packt bis zu 2.040 inhaltslose Merkmale in eine TLS-Erweiterung. Der Text ist ein aktiver Internet-Draft mit Ziel Proposed Standard und IESG-Status I-D Exists, kein RFC und kein Einsatznachweis; Revision 18 ist Pflege.
  • Ein gesetztes Bit kann Unterstützung oder Nutzungsabsicht, Vorschlag, Bestätigung oder erlaubte unaufgeforderte Mitteilung bedeuten. Die jeweilige Flag-Spezifikation bestimmt Nachrichten, Antwortpflicht und 0-RTT-Verhalten.
  • Daniel Kade schlägt eine Interpretationshülle vor, die Bit, Nachricht, Rolle, Richtung, Referenz, Transcript, Wiederaufnahme, Ergebnis und lokale Entscheidung verbindet. Sie ist redaktionelle Governance, keine IETF-Vorgabe.

Ein Compliance-Bericht zählte Server mit einer optionalen TLS-Funktion. Die Datenbasis war sauber: Für jede Verbindung lag ein Flag als Boolean vor. Erst eine Stichprobe zeigte, dass NewSessionTicket-Mitteilungen, ClientHello-Vorschläge und Serverbestätigungen in derselben Spalte gelandet waren.

Die Zählung maß Signale. Der Bericht nannte sie Aktivierungen.

Ein neues Datum ist kein neuer Reifegrad

Der Datatracker-Eintrag führt Revision 18 vom 10. September 2026 als aktiven TLS-WG-Entwurf mit beabsichtigtem Proposed-Standard-Status. Im IESG steht I-D Exists, in der Working Group Waiting for Implementation. Ein verantwortlicher AD und ein Telechat-Termin fehlen.

Dokumenthistorie und offizieller Vergleich 17→18 zeigen nur Revision, Datum und Ablaufzeit als Änderungen. Die Regeln blieben gleich. Die Verlängerung bis März 2027 ist weder RFC-Freigabe noch Interoperabilitäts- oder Verbreitungsbeleg.

Die TLS Working Group löst ein reales Platzproblem. Eine Erweiterung, deren gesamte Information in ihrer Anwesenheit liegt, kostet trotzdem vier Oktette. Viele solche Funktionen wiederholen den Rahmen. Eine gemeinsame Bitfolge senkt die Grenzkosten.

Der Container komprimiert Syntax, nicht die Zustände aller Funktionen.

Kanonische Länge bedeutet nicht kanonische Aussage

Revision 18 erlaubt ein bis 255 Oktette, also Positionen 0–2039. Bits werden vom niederwertigsten Bit an gepackt. Die Länge endet am höchsten gesetzten Bit. Ein Nullwert oder nachlaufende Nulloktette sind ungültig und führen zu einem fatalen illegal_parameter.

Damit lesen Implementierungen dieselbe Position und verwerfen mehrdeutige Formen. Doch laut Definition zeigt ein Flag Unterstützung oder Absicht zur Nutzung an.

Unterstützung ist Fähigkeit. Absicht ist Auswahl für eine Interaktion. Ein Vorschlag ist eine Nachricht. Eine Bestätigung ist ein weiterer Schritt, falls die Einzelspezifikation ihn verlangt. Tatsächliche Nutzung, Erfolg und Autorisierung sind spätere Vorgänge.

Ein gespeichertes enabled=true macht aus dieser Kette eine Behauptung, die kein einzelnes Bit trägt.

Die Nachricht bestimmt das Verb

Unaufgeforderte Flags sind in ClientHello, CertificateRequest und NewSessionTicket erlaubt. In ServerHello, EncryptedExtensions, Certificate oder HelloRetryRequest brauchen sie einen passenden früheren Vorschlag. Eine unaufgeforderte Antwort ist fatal.

Im ClientHello schlägt der Client vor. In ServerHello oder EncryptedExtensions kann der Server bestätigen. Im NewSessionTicket informiert er ohne nachfolgende Client-Antwort. Bei CertificateRequest und Certificate wechseln Rollen und Richtung.

Eine Support-Spalte verliert diese Verben. Auch ein starres offered/accepted-Modell passt nicht zu Flags ohne Antwortpflicht. Issue 19 dokumentiert, dass jede Flag-Spezifikation ihre Bestätigung selbst definiert.

Eine fehlende Antwort ist deshalb nicht allgemein eine Ablehnung.

Bestätigung ist noch keine Ausführung

Verlangt ein Flag eine Antwort, darf nur dasselbe Bit in tls_flags antworten. Benötigt die Antwort Inhalte, ist eine normale strukturierte Erweiterung nötig. Ein Bit soll keine datenhaltige Aushandlung darstellen.

Passender Vorschlag und passende Bestätigung belegen die Signalisierungsregel. Sie belegen weder spätere Ausführung noch Erfolg, lokale Freigabe oder eine Anwendungsentscheidung.

RFC 8446 zeigt dies mit post_handshake_auth. Der Client erklärt Bereitschaft zu späterer Authentisierung. Das beweist keinen CertificateRequest, keine Zertifikatsantwort und keine Berechtigung. Bereitschaft, Anforderung, Abschluss und Autorisierung sind getrennte Zustände.

0-RTT verlangt eine Zeitgrenze

Bei TLS-1.3-Wiederaufnahme können 0-RTT-Daten vor Abschluss des neuen Handshakes fließen. Der Flag-Container kann in den Nachrichten vorkommen, gibt aber nicht allen künftigen Flags dieselbe Early-Data-Bedeutung. Die jeweilige Spezifikation muss ihre Interaktion definieren.

Issue 16 hält diese Arbeitsteilung fest: Der Container ist Encoding-Framework; die dargestellten Erweiterungen verantworten 0-RTT. Eine Funktion darf Zustand aus einem Ticket übernehmen, eine andere braucht neue Bestätigung, eine dritte gilt erst für die nächste Wiederaufnahme.

Ohne full/resumed, 0-RTT-Angebot und -Annahme, Ticket und Entscheidungszeit kann ein späteres true rückwirkend auf frühere Bytes angewendet werden. Bei Identität oder Sicherheit würde eine noch nicht bestehende Erlaubnis nachträglich behauptet.

Nicht gesehen ist nicht nicht gesendet

Der Entwurf warnt, dass Bestätigungen in ServerHello und HelloRetryRequest passiv sichtbar sind. Wo keine Offenlegung nötig ist, sollten meist verschlüsselte Nachrichten genutzt werden.

Ein Pfadsensor sieht klare Nachrichten, nicht aber EncryptedExtensions. Ein Endpoint-Log sieht das entschlüsselte Transcript, besitzt dafür eine andere Vertrauens- und Aufbewahrungsgrenze. Ein TLS-Terminator bezeugt sein eigenes Segment.

„Flag fehlt“ benötigt daher Beobachtungspunkt, sichtbare Nachrichten, Capture-Fenster und Parserstand. Schweigen des Sensors darf nicht als Schweigen des Peers gelten.

Ein Registry-Eintrag ist kein Laufzeitnachweis

Revision 18 verlangt ein TLS Flags Registry mit Value, Flag Name, Message, Recommended und Reference. Werte 0–15 erfordern Standards Action; 16–2039 Specification Required nach RFC 8126. Als erster Eintrag ist Wert 8 resumption_across_names in NewSessionTicket mit Recommended N vorgesehen.

Zum Stichtag listete das IANA ExtensionType Registry den Container tls_flags bereits als Erweiterung 62 für CH/SH/HRR/EE/CR/CT/NST, Recommended N, mit Verweis auf Revision 14. Das ist Koordinationsstand, kein Produkt- oder Aktivierungszertifikat.

RFC 8447 erklärt, dass N nicht zwingend fehlerhaft bedeutet. Begrenzte Anwendbarkeit, Sonderzweck oder fehlender Konsens kommen infrage. Die Expertenregistrierung ist keine Empfehlung. Issue 32 führte zur Ausrichtung an Y/N/D und zur Klarstellung, dass spätere Dokumente den Wert ändern können.

Auch TLS 1.3 bis und TLS Registry bis sind laufende Arbeiten. Das Registry verweist auf Bedeutung; nur Transcript und Folgereignisse belegen eine Verbindung.

Fatal beschreibt den Regelverstoß, nicht die Ursache

Nullwert, nicht minimale Länge oder Antwort ohne Vorschlag können den Handshake beenden. Belegbar sind Nachricht, Richtung, Bytes, Regel und Alert.

Nicht automatisch belegt sind veraltete Bibliothek, altes Registry, Serializerfehler, falsches Experiment oder Angriff. Diese Diagnose braucht eigene Evidenz. Das Protokollereignis wird zuerst festgehalten; Ursache, Verantwortlicher, Abhilfe und Wiederfreigabe folgen getrennt.

Eine Interpretationshülle pro Flag

Daniel Kades Flag-Interpretationshülle bewahrt eine begrenzte Transcript-Referenz ohne Geheimnisse, TLS-Version, vollständigen oder wiederaufgenommenen Handshake, 0-RTT-Zustand, Senderrolle, Richtung, Nachricht, Containerwert, Rohwert-Hash, kanonische Länge, Position, Registry-Snapshot sowie definierendes Dokument und Revision.

Sie klassifiziert Vorschlag, Bestätigung oder erlaubte unaufgeforderte Mitteilung, nennt Antwortpflicht und zugehörigen früheren Vorschlag. Passive und Endpoint-Sicht bleiben getrennt; Parser- und Policy-Version werden festgehalten.

Schließlich enthält sie das beobachtete Ergebnis: verstanden, ausgewählt, ausgeübt, gescheitert, ersetzt oder unbekannt. Zulässige Entscheidung, Eigentümer, Verbraucher, Aufbewahrung, Unsicherheit, Ablauf und Abschluss kommen hinzu.

Die Hülle ist kein IETF-Erfordernis und ändert TLS nicht. Sie verhindert, dass ein wahrer Nachrichtenbefund zu einem unbelegten Funktionszustand anwächst.

Behauptungen stufenweise erhöhen

„Bit 8 in NewSessionTicket gesehen“ ist Beobachtung. „Server kündigte namensübergreifende Wiederaufnahme nach Revision R an“ ist Interpretation. „Client versuchte sie“ ist Ausführung. „Server akzeptierte unter Policy P“ ist Entscheidung. „Anwendung autorisierte Identität“ braucht weiteren Beleg.

Der Container spart wiederholte Bytes. Die Verben der Beweiskette darf er nicht einsparen. Ein TLS-Flag belegt ein Bit in einer Nachricht; allein ist es kein Zustandsprotokoll der Funktion.

Quellen