Zusammenfassung

  • In TLS/DTLS 1.2 dürfen Clients nach RFC 10015 FFDH-, FFDHE- und RSA-Schlüsseltausch-Suites nicht anbieten und Server sie nicht auswählen; statisches ECDH steht unter SHOULD NOT.
  • Die Regel ist versions- und funktionsgebunden: FFDHE bleibt in TLS/DTLS 1.3 zulässig, und ein RSA-Zertifikat kann einen erlaubten ephemeren Austausch authentisieren.
  • Ein IANA-D dokumentiert die gemeinsame Klassifikation, ändert aber keinen Prozess. Endpunktinventar, Positiv- und Negativproben, Fehlerursachen, befristete Ausnahmen und Driftkontrolle liefern den Betriebsnachweis.

Der Erfolg, der nach der Änderung verschwinden muss

Ein alter Client baut nach einer Härtung weiterhin eine TLS-1.2-Verbindung auf. Die Verfügbarkeit bleibt grün, das Zertifikat ist gültig, die Anwendung antwortet. Der Bericht nennt das Ergebnis „voll kompatibel“.

Ausgehandelt wurde eine TLS_RSA_*-Suite.

Nach RFC 10015 ist gerade dieser Erfolg ein Fehler der Stilllegung. Das im Juli 2026 auf dem Standards Track veröffentlichte Dokument verlangt für TLS und DTLS 1.2: Ein Client darf eine RSA-Schlüsseltausch-Suite nicht anbieten, ein Server darf sie nicht auswählen.

Der Versionszähler kann diese Aussage nicht treffen. TLS 1.2 ist ein Rahmen, keine Beschreibung der Geheimnisbildung. Zertifikatsprüfung, Schlüsseltausch, symmetrische Verschlüsselung und Integrität sind getrennte Entscheidungen. Ein Proxy kann außerdem anders auswählen als der Ursprung, obwohl beide unter demselben Dienstnamen erscheinen.

Drei Verbote und eine starke Warnung

RFC 10015 trennt endliche Felder und elliptische Kurven sowie statische und ephemere Schlüssel. FFDH ist nicht-ephemeres Diffie-Hellman über einem endlichen Feld; der statische öffentliche DH-Schlüssel steckt im Zertifikat. FFDHE sendet einen temporären Wert im Handshake. ECDH und ECDHE bilden die entsprechende Unterscheidung auf elliptischen Kurven.

Für TLS/DTLS 1.2 gilt:

  • nicht-ephemeres FFDH: Angebot und Auswahl MUST NOT;
  • FFDHE: Angebot und Auswahl MUST NOT;
  • RSA-Schlüsseltausch: Angebot und Auswahl MUST NOT;
  • nicht-ephemeres ECDH: Angebot und Auswahl SHOULD NOT.

Die festen Zertifikatstypen rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh und ecdsa_fixed_ecdh sollen ebenfalls nicht verwendet oder akzeptiert werden. Sie gelten nur für Version 1.2 und älter.

Die unterschiedliche Normstärke muss sich in der Ausnahmeführung wiederfinden. Statisches ECDH verlangt einen außergewöhnlichen, dokumentierten Grund und ein Ende, ist aber nicht dasselbe absolute Verbot. Bei RSA oder FFDHE genügt eine schlechtere Priorität nicht: Solange die Suite bei fehlender Alternative wählbar bleibt, lebt der Pfad.

Warum einfache Namensfilter die Grenze verfehlen

Ein RSA-Zertifikat ist nicht automatisch RSA-Schlüsseltausch. Seine RSA-Signatur kann einen ECDHE-Austausch authentisieren, dessen Geheimnis ephemer entsteht. „Alles mit RSA sperren“ würde erlaubte Kombinationen beseitigen.

Auch „DHE überall sperren“ wäre falsch. RFC 10015 sagt ausdrücklich, dass FFDHE in TLS und DTLS 1.3 die für 1.2 beschriebenen Probleme nicht teilt und weiter angeboten werden darf. Der Policy-Entscheid muss Version und Suite gemeinsam betrachten.

Darum besteht die kleinste belastbare Aussage aus Endpunkt, geladener Konfiguration, Client-Angebot, Server-Auswahl, Version und Ergebnis. Eine Zertifikatsliste oder ein Versionsscan allein schließt die Beweiskette nicht.

Weshalb Ephemerität FFDHE 1.2 nicht rettet

Ephemere Schlüssel verbessern Forward Secrecy, lösen aber nicht die Gruppenauswahl. In TLS 1.2 verbreiteten sich kundenspezifische endliche Gruppen. Ein Client kann ihre mathematischen Eigenschaften während eines Handshakes praktisch nicht vollständig prüfen. Lehnt er eine Gruppe ab, fehlt ein sauberer Weg zu anderen akzeptablen Parametern.

RFC 7919 standardisierte benannte FFDHE-Gruppen und beschrieb den Kompatibilitätsdruck, der breit unterstützte Größen konservierte. RFC 10015 nennt kleine Untergruppen, weiter eingesetzte 1024-Bit-Gruppen und wiederverwendbare Vorberechnungen gegen populäre Gruppen. Wenn vermeintlich ephemere Geheimnisse wiederverwendet werden, kommt die Raccoon-Klasse von Timing-Angriffen hinzu.

Das „E“ im Suite-Namen belegt somit weder sichere Parameter noch einen frischen geheimen Wert. Die Entscheidung richtet sich gegen die konkrete 1.2-Konstruktion und ihre Betriebsgeschichte, nicht gegen Diffie-Hellman als Familie.

RSA macht aus einem schwachen Endpunkt ein historisches Problem

Beim RSA-Schlüsseltausch erzeugt der Client das Premaster Secret und verschlüsselt es für den RSA-Schlüssel des Servers. Forward Secrecy fehlt. Gespeicherter Verkehr kann nach einer späteren Offenlegung des privaten Schlüssels rückwirkend gefährdet sein.

Bleichenbacher-Orakel nutzen sichtbare Unterschiede bei ungültigen RSA-Chiffretexten. Varianten wie ROBOT und DROWN zeigen, wie schwer vollkommen ununterscheidbare Gegenmaßnahmen sind. In TLS/DTLS 1.2 fehlt zudem eine bequeme Key-Domain-Separation. Mehrere Endpunkte teilen oft denselben privaten RSA-Schlüssel; das schwächste System kann deshalb die Bewertung aller anderen verändern.

Ein Zertifikatsablaufplan reicht nicht. Die Organisation braucht eine Karte der privaten Schlüssel-Fingerprints und ihrer Wiederverwendung.

Das Register klassifiziert, der Prozess entscheidet

RFC 10015 aktualisiert siebzehn frühere RFCs, darunter TLS 1.2, DTLS 1.2 und BCP 195. Das IANA-Register führt die betroffenen Einträge mit D und dem neuen Verweis. RFC 9847 definiert D als für neue Implementierungen oder Deployments abgeraten.

Diese Metadaten schaffen eine gemeinsame Sprache. Sie ändern weder Bibliothek noch Kryptoprovider, Framework, Proxy, Load Balancer, CDN oder Firmware. Selbst ein korrekter Repository-Diff kann durch eine Laufzeitvariable oder regionale Vorlage überschrieben werden.

Der Diff belegt Absicht. Die geladene Konfiguration belegt Prozesszustand. Erst Angebot und Auswahl belegen, dass der alte Kompatibilitätspfad nicht mehr zustande kommt.

Vor dem Schnitt ein Aushandlungsbuch führen

Das Inventar umfasst öffentliche Listener, interne APIs, ausgehende Clients, DTLS, Service Meshes, Proxies, Edge-Terminationen, Appliances und eingebettete Geräte. Zu jedem Eintrag gehören Eigentümer, Bibliothek, Kryptoprovider, effektive Suites, Versionsgrenzen, SNI/ALPN, Zertifikatsnutzung, Schlüsselwiederverwendung, Region und Gegenstellen.

In der Baseline werden erfolgreiche Verbindungen mit Version, Suite, Schlüsseltausch, entscheidender Termination und Anwendungscanary verbunden. Fehler erhalten die erste handlungsfähige Ursache: keine gemeinsame Suite, Gruppe, Zertifikat, Version oder Anwendungsfehler nach erfolgreichem Transport.

Deterministische Proben prüfen beide Richtungen. Ein Client mit ausschließlich RSA oder FFDHE in 1.2 muss scheitern. Ein erlaubter ephemerer 1.2-Pfad muss funktionieren. TLS 1.3 und sein zulässiges FFDHE müssen erhalten bleiben. Bei gemischtem Angebot darf kein stiller Rückfall auftreten.

Der Rollout folgt Besitzgrenzen: Listenerklasse, Region, Proxy-Stufe oder Clientkohorte. Vorher/nachher-Fingerprints, Handshake-Stichproben, Fehlerverteilung und begrenztes Rollback bleiben erhalten. „Datei verteilt“ ist ein Ereignis; „verbotene Aushandlung verschwunden, erlaubte Aushandlung verfügbar“ ist das Ergebnis.

Laufender Code setzt die Tatsachengrenze

Heng Lus Primat des laufenden Codes trennt Erklärung und Vollzug. Ein RFC kann die Bedingung bestimmen, IANA kann sie katalogisieren. Keines von beiden erzeugt den Produktions-Handshake.

Das Modell einer minimalen Anfangsspezifikation und lokalisierten Zukunftsentscheidung lässt die gemeinsame Inkompatibilitätsregel dünn und die Umstellung beim Teilnehmer. Dieser behält Inventar, Reihenfolge, Ersatz, Isolation, Ausnahme und Rollback. Lokale Zuständigkeit erlaubt nicht, eine verbotene Suite kompatibel zu nennen; sie benennt den Träger und das Ende der Übergangskosten.

RFC 10015 zeichnet die Linie. Der Endpunkt muss zeigen, dass sie in seiner laufenden Realität existiert.