Zusammenfassung

  • Für TLS 1.2 und DTLS 1.2 untersagt RFC 10015 Clients das Anbieten und Servern die Auswahl mehrerer Finite-Field-Diffie-Hellman-Verfahren sowie des statischen RSA-Schlüsselaustauschs. Statisches ECDH und feste DH-Clientzertifikattypen bleiben auf der Stufe SHOULD NOT.
  • Das D bei IANA belegt eine Entscheidung im Standard, nicht deren Vollzug. Eine belastbare Deaktivierung verbindet Normstärke, wirksame Konfiguration, Reload, sämtliche Terminierungspunkte, Negativtests, Aushandlungstelemetrie und den Abschluss befristeter Ausnahmen.

Im zentralen Regelwerk war die Suite bereits verschwunden. Das Compliance-Board zeigte Grün. Ein alter DTLS-Terminator, der von einem anderen Team betrieben wurde, lief trotzdem mit dem vorigen Image weiter. Weder das Regelwerk noch das Gerät logen; nur das Wort „erledigt“ verband zwei Tatsachen, die nie zusammen geprüft worden waren.

RFC 10015 ist ein Standards-Track-Dokument der IETF. Es aktualisiert die Vorgaben für Schlüsselaustausch in TLS 1.2 und DTLS 1.2. Es misst keine Verbreitung, bewertet keinen Hersteller und prüft keinen konkreten Dienst. Der Standard sagt, was konforme Gegenstellen nicht mehr tun sollen oder dürfen. Er behauptet nicht, dass laufende Systeme die Vorgabe bereits ausführen.

Gerade maschinenlesbare Register laden zu dieser Verwechslung ein. Eine Automation liest einen geänderten Wert, erzeugt eine Regel und schließt einen Kontrollpunkt. Zwischen der Registerzeile und einem Handshake liegen jedoch Bibliothekscode, Produktvorgaben, lokale Richtlinien, gerenderte Konfiguration, Prozesszustand, die tatsächliche TLS-Terminierung und das Angebot des Clients.

Nicht alles Alte trägt dasselbe Verbot

RFC 10015 unterscheidet Verfahrensfamilien und normative Stärke. In TLS 1.2 und DTLS 1.2 MUST NOT ein Client nicht-ephemere Finite-Field-DH-Suites anbieten; ein Server darf sie nicht auswählen. Dasselbe MUST NOT gilt in diesen Versionen für ephemere DHE-Suites. Auch statischer RSA-Schlüsselaustausch fällt unter das Verbot.

Statisches ECDH bleibt dagegen SHOULD NOT. Die behandelten ClientCertificateType-Werte für festes DH stehen ebenfalls auf SHOULD NOT. Eine Abweichung braucht einen außergewöhnlichen, überprüfbaren Grund, ist semantisch aber nicht dasselbe wie ein Verstoß gegen MUST NOT. Wer beides nur als „deprecated“ speichert, vernichtet die Information, die eine Ausnahme überhaupt erst steuerbar macht.

Auch die Protokollversion gehört zur Aussage. RFC 8996 hatte TLS 1.0 und 1.1 bereits abgekündigt. RFC 5246 spezifiziert TLS 1.2, RFC 8446 gestaltet den Schlüsselaustausch in TLS 1.3 neu. RFC 10015 lässt FFDHE in TLS 1.3 ausdrücklich zu. Probleme des TLS-1.2-Designs machen nicht jedes Finite-Field-DHE in jeder Version unzulässig. RFC 7919 liefert weiterhin den Kontext für ausgehandelte Gruppen.

„Statisches RSA“ bedeutet ebenso wenig „jegliches RSA“. Ein Dienst kann ein RSA-Zertifikat und RSA-Signaturen einsetzen, ohne statischen RSA-Schlüsseltransport zu verwenden. Eine Suche im Zertifikatsbestand beantwortet daher nicht die Frage, welchen Schlüsselaustausch ein Endpunkt auswählen kann.

Die kryptografischen Gründe erklären die Schärfe. Ohne Forward Secrecy kann der spätere Verlust eines Langzeitschlüssels alte Sitzungen offenlegen. Wiederverwendete Finite-Field-DH-Schlüssel bringen Timing- und Gruppenrisiken; wiederverwendete ECDH-Schlüssel schaffen Angriffsflächen für ungültige Kurven, Seitenkanäle und Fehler. Statisches RSA trägt die wiederkehrende Klasse der Bleichenbacher-Angriffe sowie Schlüsselwiederverwendung über Protokolle hinweg. RFC 9325 und RFC 9847 stehen im größeren Zusammenhang fortgeschriebener TLS-Empfehlungen: historische Verfügbarkeit ist kein dauernder Sicherheitsnachweis.

Was das D tatsächlich belegt

Die IANA TLS Parameters markieren die betroffenen Suites und vier ClientCertificateType-Kennungen mit D und verweisen auf RFC 10015. D steht für discouraged. Ob daraus MUST NOT oder SHOULD NOT folgt, bestimmt die referenzierte Norm.

Damit belegt die Markierung den aktuellen Empfehlungsstatus im öffentlichen Register. Sie kann Quellcodeprüfungen, Beschaffungsregeln und Migrationen auslösen. Sie belegt nicht, dass die Bibliothek die Fähigkeit entfernt, ein Produkt seinen Standard geändert, ein Betreiber die Suite aus der lokalen Konfiguration gestrichen oder der laufende Prozess diese Änderung geladen hat.

Ebenso wenig erfasst sie automatisch jeden Listener, SNI-Namen, Proxy, Load Balancer und regionalen Edge. Sie beweist weder das Ende von Client-Angeboten noch das Ende von Server-Auswahlen. Auch Ausnahmepfade oder Rollback-Images können den Mechanismus wiederbringen. Das sind eigenständige Behauptungen mit verschiedenen Eigentümern und Zeitständen.

Fähigkeit, Angebot, Auswahl und Beobachtung

Ein brauchbares Betriebsmodell führt vier Spalten. Fähigkeit heißt, dass Code den Austausch ausführen kann. Angebot beschreibt die Kandidaten eines konkreten Client-Handshakes. Auswahl ist die Entscheidung des Servers. Beobachtung ist der Ausschnitt, den Scanner oder Telemetrie tatsächlich gesehen haben.

Eine Bibliothek kann fähig bleiben, obwohl eine Richtlinie alle Angebote verhindert. Eine Suite kann in einer Datei stehen und trotzdem nie ausgewählt werden. Ein Scanner kann nichts finden, weil er einen SNI-Pfad nicht kennt, UDP nicht prüft, einen internen Edge auslässt oder stets eine bessere Alternative anbietet. Nicht beobachtet bedeutet nicht unmöglich.

Ein kontrollierter Negativtest bietet ausschließlich die verbotene Familie an und erwartet Ablehnung. Er ist aussagekräftiger als eine normale Verbindung eines modernen Browsers, gilt aber nur für Adresse, Port, Transport, SNI, Zeitpunkt und Richtlinienversion des erreichten Terminators. DTLS 1.3 in RFC 9147 unterstreicht: Ein TLS-Scan über TCP schließt keine DTLS-Exposition über UDP.

Der Abkündigungs-Abschlussbeleg

Für jede Exposition sollte ein Abkündigungs-Abschlussbeleg entstehen. Sein erster Teil nennt RFC, IANA-Kennung, Protokollversion, Verfahrensfamilie und Normstärke. So wird zulässiges FFDHE in TLS 1.3 nicht wegen einer Namensähnlichkeit entfernt und ein SHOULD NOT nicht unbemerkt zum MUST NOT erklärt.

Der zweite Teil bestimmt die wirksame Kontrollstelle: autoritative Konfigurationsquelle, freigegebene Revision, gerenderte Richtlinie, Software- oder Geräteversion, Listener, SNI, Adresse, Port, Transport und vorgeschaltete Proxys. „Globale Policy aktualisiert“ ist bei verteilter Terminierung lediglich Absicht.

Der dritte Teil weist Aktivierung nach: Neustart, Hot Reload oder verwalteter Rollout; Zeitpunkt; Änderungskennung; Zielpopulation; erfolgreiche, fehlgeschlagene und fehlende Instanzen; Rollback-Version. Ein Diff zeigt, was geschehen sollte. Prozessidentität und geladene Policy rücken näher an das heran, was geschah.

Der vierte Teil dokumentiert Verhalten: Ablehnung eines ausschließlich verbotenen Angebots, Auswahl bei realistischen Alternativen, beobachtete Angebote und Auswahlen, Messzeitraum und Stichprobenlücken. Der Beleg übersetzt „nicht gesehen“ niemals in „kann nicht passieren“.

Zum Schluss werden Abhängigkeiten und Ausnahmen benannt: alter Client, Geschäftszweck, Umfang, kompensierende Maßnahme, verantwortliche Person, Genehmigung, Ablauf und Ausstiegskriterium. Sowohl die Migration des Clients als auch die Entfernung des Kompatibilitätspfads brauchen einen Nachweis. Ohne Ablaufdatum ist eine Ausnahme keine Brücke, sondern eine zweite Richtlinie.

Dieser Beleg ist ein Governance-Vorschlag von Daniel Kade, keine zusätzliche Anforderung aus RFC 10015. Er verhindert, dass eine schnell eingelesene Normänderung eine maschinell erzeugte Gewissheit über nie geprüfte Infrastruktur wird.

Verben, die zur Beweislage passen

Automation sollte „im Register abgekündigt“, „aus der Konfiguration entfernt“, „Reload bestätigt“, „Negativangebot abgelehnt“, „innerhalb dieser Abdeckung keine Auswahl beobachtet“ oder „Ausnahme geschlossen“ melden. „Deaktiviert“ folgt erst, wenn die relevanten Terminierungspfade geschlossen sind.

Diese Genauigkeit bewahrt auch Ursachen. Taucht eine verbotene Auswahl wieder auf, lässt sich zwischen Quelle, Rendering, Rollout, Inventar, Ausnahme und abhängiger Clientmigration unterscheiden. Ein einzelnes grünes Bit zeigt keinen Weg zurück zum Fehler.

Die Standardisierung hat die Startlinie markiert. Die Betriebsführung muss nun beantworten, welcher laufende Endpunkt die alte Wahl noch treffen kann, wer ihn kontrolliert und welcher Nachweis diese Möglichkeit beendet.

Quellen