Zusammenfassung

  • RFC 3546 verlangte 2003 für neue TLS-Erweiterungen und Alert-Nummern eine IETF Standards Action, weil Wechselwirkungen zwischen Funktionen die Gesamtsicherheit mindern konnten.
  • RFC 8447 stellte 2018 ExtensionType-Werte von 0 bis 254 auf Specification Required um und trennte davon die Angabe „Recommended“.

Der historische Wandel bestand nicht bloß darin, dass TLS mehr Erweiterungsnamen erhielt. Geändert hat sich, wie solche Namen in einen gemeinsamen Namensraum gelangen – und wie klar Registrierung und Empfehlung auseinandergehalten werden.

RFC 3546 führte im Juni 2003 ein allgemeines Format für Erweiterungen in TLS-Hello-Nachrichten ein und definierte sechs erste Typen. Der Codepunkt bezeichnet den Typ; die Erweiterungsdaten tragen dessen konkrete Bedeutung. Das Dokument behandelte auch neue Alert-Nummern. Neue Erweiterungen und Alerts sollten eine IETF Standards Action durchlaufen, weil neue und bestehende Funktionen so zusammenwirken konnten, dass die Gesamtsicherheit sank. Das erklärte nicht jeden Vorschlag für gefährlich. Es erkannte an, dass eine Einzelprüfung Wechselwirkungen übersehen kann.

Im Protokoll gab es eine verwandte Vorsichtsmaßnahme. Vor der Authentisierung des TLS-Handshakes konnte ein aktiver Zwischenknoten Hello-Erweiterungen verändern. Finished-Nachrichten binden normalerweise den Handshake-Inhalt ein; dennoch mussten Entwickler prüfen, ob andere Funktionen Bedeutung und Folgen dieser Nachrichten veränderten. Das war eine Bedrohungsannahme und Entwurfsaufgabe, kein Bericht über einen beobachteten Angriff. Die Registerpolitik regelt den Eintritt neuer Bedeutungen in den gemeinsamen Namensraum; der Protokollschutz authentisiert Nachrichten in einer konkreten Verbindung.

2006 löste RFC 4366 RFC 3546 ab. Die Zuweisung von ExtensionType wurde als IETF Consensus beschrieben; neue Werte sollten über vom IESG gebilligte RFCs kommen. Die Begriffe änderten sich, der Weg blieb aber im IETF-Prozess verankert. 2018 hielt RFC 8447 eine andere Prozesseinschätzung fest: Die Erfahrung habe gezeigt, dass IETF Review für TLS-Erweiterungen zu streng sei. Werte mit einem ersten Oktett von 0 bis 254 wechselten zu Specification Required; 255 wurde für Private Use reserviert.

Specification Required bedeutet nicht, dass es keine Prüfung gibt. RFC 8126 verlangt dauerhafte, öffentlich zugängliche Dokumentation, die für Interoperabilität ausreicht, sowie die Prüfung durch einen benannten Experten. RFC 8447 sieht zusätzlich drei Wochen Begutachtung auf der TLS-Registry-Mailingliste mit Expertenrat vor. Der Experte prüft, ob eine öffentliche Spezifikation vorliegt; eine vertiefte Prüfung ist möglich, doch die Zustimmung ist ausdrücklich keine Empfehlung der Erweiterung. Aus dem breiten Standardverfahren wurde ein dokumentierter, überprüfbarer Vorschlag.

RFC 8447 ergänzte auch die Spalte „Recommended“. Sie zeigt getrennt, welche Parameter Implementierungen im Allgemeinen unterstützen sollten. N bedeutet nicht zwingend mangelhaft: Es kann fehlenden IETF-Konsens, begrenzte Anwendbarkeit oder einen besonderen Anwendungsfall anzeigen. Umgekehrt belegt eine Zuweisung nur, dass ein Name nach den Registerregeln eingetragen ist. Sie belegt weder Softwareunterstützung noch Aushandlung zwischen Kommunikationspartnern, betriebliche Aktivierung oder eine positive Sicherheitsbewertung.

Die begrenzte Lehre lautet: Register koordinieren gemeinsame Kennungen, können aber Spezifikation, Empfehlung, Implementierung und beobachteten Betrieb nicht zu einem einzigen Merkmal verdichten. RFC 3546s Sorge vor Wechselwirkungen verschwand nicht mit dem gelockerten Verfahren. Die Prüfung verteilt sich nun auf öffentliche Dokumentation, Fachleute, Standardisierung und lokale Implementierungsentscheidungen. Wer das Register liest, sollte diese Belege getrennt halten.

Quellen