Zusammenfassung

  • RFC 9852 / BCP 195, mitverfasst von Rich Salz und Nimrod Aviram, verlangt von einem neuen TLS-nutzenden Protokoll, TLS 1.3 als verfügbar anzunehmen und als Standard zu spezifizieren. Die Pflicht richtet sich an die neu geschriebene Spezifikation.
  • Sie ist keine Quittung eines laufenden Endpunkts. Ausgehandelte Version, Konfiguration, Gegenstellenauthentisierung, Anwendungsannahme und Wiederherstellung sind getrennte Tatsachen. DTLS schließt der RFC ausdrücklich von dieser Vorschrift aus.

„Muss“ ist in einem Standard ein nützliches Wort: Es verhindert, dass eine geklärte technische Wahl wie eine beliebige Option aussieht. Aus einer normativen Regel wird dadurch aber keine Messung. Wenn ein RFC TLS 1.3 als Standard fordert, hat er nicht beobachtet, welche Version ein bestimmter Client mit einem bestimmten Endpunkt tatsächlich ausgehandelt hat.

RFC 9852, New Protocols Using TLS Must Require TLS 1.3, ist eine IETF Best Current Practice, BCP 195. Rich Salz und Nimrod Aviram werden als Autoren genannt; der Text ist IETF-Konsens und keine individuelle Betriebsaussage. Er beantwortet eine begrenzte Designfrage: Was soll eine neue Spezifikation schreiben, die TLS verwendet? Sie soll TLS 1.3 als verfügbar voraussetzen und es zum Standard erklären.

Damit sind Betriebsfragen nicht erledigt. Ein Betreiber muss weiterhin feststellen, welche Version Client und Endpunkt tatsächlich vereinbarten, welche lokale Richtlinie gewählt wurde, ob die erforderliche Peer-Authentisierung gelang, ob die Anwendung die Sitzung annahm und wie ein Fehler erkannt und behoben wurde. Für jede dieser Verbindungen gibt es einen anderen Verantwortlichen und andere Beobachtungen.

Die DTLS-Grenze gehört zum Kern der Aussage. RFC 9852 sagt, die Vorschrift gelte nur für TLS. Weil DTLS 1.3 nicht breit verfügbar oder eingesetzt sei, gelte sie für keine DTLS-Version. Eine Kurzform wie „TLS 1.3 ist Pflicht“ löscht die ausdrücklich gesetzte Reichweite und macht aus einer Regel für neue TLS-Protokolle eine Pauschalbehauptung.

Der RFC begründet die Richtung damit, dass TLS 1.3 weit verbreitet sei, umfassende Sicherheitsbeweise habe und Sicherheits- sowie Datenschutzdefizite von TLS 1.2 verbessere. Zugleich hält er fest, dass TLS 1.2 mit angemessener, oft maßgeschneiderter Konfiguration gute Eigenschaften liefern kann. Post-Quantum-Migration ist ein Grund für die Richtung; wann eine bestimmte Anwendung PQC braucht, liegt außerhalb des Dokuments. Das sind Gründe für eine Designregel, keine Telemetrie eines Dienstes.

Running-Code-Primacy verlangt daher getrennte, sauber verknüpfte Nachweise. Die BCP belegt die Designregel. Eine Konfiguration belegt lokale Absicht. Eine Handshake-Beobachtung belegt eine Verbindungsfakt. Authentisierungs-, Anwendungs- und Wiederherstellungsprotokolle belegen jeweils etwas anderes. Eine einzige Compliance-Markierung kann diese Kette nicht ersetzen.

Der Protokollautor folgt also BCP 195 beim Schreiben. Betreiber melden eine Einführung erst, wenn Richtlinie, beobachtete Verhandlungen, erforderliche Authentisierung, Anwendungsergebnis und Wiederherstellung prüfbar sind. Dann stützen Standard und System einander, ohne füreinander auszugeben.

Quellen