Zusammenfassung

  • RFC 3436 koppelte gegenläufige SCTP-Streams gleicher Nummer und legte auf jedes Paar eine eigene TLS-Verbindung; Session-Wiederaufnahme sparte Aufwand, ersetzte aber nicht den Verbindungs-Handshake.
  • Geschützte Streams mussten geordnet und vollständig zuverlässig sein. TLS schützte Nutzdaten, nicht die gesamte SCTP-Steuerung; RFC 6083 wählte später eine DTLS-Verbindung pro Association.

Kein einheitlicher Sicherheitszustand

In derselben SCTP-Association konnte Stream 0 vollständig ausgehandelt sein, Stream 1 eine Session wiederaufnehmen, Stream 2 bis zur ersten Nutzung warten und Stream 3 natives SCTP tragen. Unidirektionale Streams waren für dieses TLS ungeeignet. Ein grüner Status für die ganze Association verwischte reale Unterschiede.

RFC 3436 erschien im Dezember 2002. Text, RFC-Editor-Akte und IETF-Datensatz belegen die Spezifikation, nicht Implementierung, Interoperabilität oder Einsatz.

TLS 1.0 erwartete einen zuverlässigen, geordneten Bytestrom. SCTP bot Nachrichten, mehrere Streams und Multihoming. RFC 3436 änderte keines der Protokolle: Ein TLS-Record wurde zu einer SCTP-Nutzernachricht. SCTP fragmentierte und setzte sie wieder zusammen; mindestens 18.437 Byte (2^14 + 2048 + 5) mussten möglich sein.

Gleiche Streamnummern beider Richtungen bildeten ein bidirektionales Paar. Jedes geschützte Paar erhielt Verbindung und Handshake. Dieser konnte vollständig, als Wiederaufnahme oder erst bei Nutzung erfolgen. Eine gemeinsame Session machte daraus keine gemeinsame Verbindung; jeder Stream brauchte seinen eigenen Abschluss.

Der Preis der seriellen Records

TLS verlangte strikte Reihenfolge. Ungeordnete Zustellung und begrenzte Lebensdauer waren daher verboten, unidirektionale Streams ausgeschlossen. Die partielle Zuverlässigkeit aus RFC 3758 passte nicht in diese serielle Folge.

RFC 4895 benannte die tiefere Grenze: RFC-3436-TLS schützte nur SCTP-Nutzdaten, nicht alle Chunks. SCTP-AUTH musste Transportsteuerung separat authentisieren. Verschlüsselter Inhalt, TLS-Identität und authentisierte DATA- oder Steuer-Chunks waren verschiedene Belege.

Auch Multihoming war keine Identität. Records durften von einer anderen IP eintreffen; Sicherheitsentscheidungen mussten auf dem authentisierten Peer beruhen.

RFC 6083 nannte vier ernsthafte Grenzen: keine ungeordnete Zustellung, keine partielle Zuverlässigkeit, gleiche Streamzahl in beiden Richtungen und eine TLS-Verbindung je Paar. DTLS verwendete stattdessen eine Verbindung innerhalb der Association, legte geordnete Sicherheitssteuerung auf Stream 0 und erlaubte Anwendungsdaten auf vielen Streams. Erforderliche DATA- und FORWARD-TSN-Chunks wurden mit SCTP-AUTH geschützt.

RFC 8996 verwarf später TLS 1.0 und 1.1. Die Kryptografie von 2002 ist historische Mechanik. Heng Lus Realitätsebenen, Vorrang laufenden Codes und minimale Anfangsspezifikation helfen rückblickend, Norm, Handshake, Steuerbeleg und Wirkung auseinanderzuhalten.

Die präzise Aussage lautete: Dieser Stream schloss diese Verbindung für diese Identität unter diesen Regeln ab; die Association-Steuerung brauchte einen eigenen Nachweis.

Quellen

Weitere eingefrorene Belege