Zusammenfassung

  • Der individuelle Internet-Draft vom 27. Oktober will den TLS-1.3-Schlüsselplan über schedule_profile getrennt von der Cipher Suite aushandeln. Anders als die Fassung vom Juli umfasst er nun DTLS und Exported Authenticators.
  • Läuft ein solcher Authentifikator außerhalb der TLS-Bibliothek, muss er die verhandelte KDF-Kennung oder die Information über den unveränderten Standardpfad und zusätzlich TLS oder DTLS erfahren. Die reine Exporter-API reicht dafür nicht.

Auf einem Prüfprotokoll steht TLS_AES_128_GCM_SHA256. Eine Verwaltung trägt SHA-256 als Schlüsselplan ein und setzt einen Haken. Unter dem neuen XOF-Entwurf kann dieser Haken danebenliegen: Die Cipher Suite behält ihren Namen und die Wahl des AEAD-Verfahrens, während schedule_profile SHAKE256 oder TurboSHAKE256 für sämtliche Schlüsselableitungen und den Transkript-Hash bestimmt. Ohne die Erweiterung läuft weiter der HKDF-Plan aus TLS 1.3. Mit ihr erzählt das Typenschild nur noch einen Teil der Geschichte.

Die neue Reichweite lässt sich an den Versionen ablesen. Fassung 00 schloss DTLS 1.3 und Exported Authenticators ausdrücklich aus. Fassung 01 will vier RFCs aktualisieren und beschreibt in Abschnitt 14.2, wie die spätere Authentifizierung zu berechnen ist. RFC 9261 erlaubt beiden Seiten, sich nach dem Handshake zu authentifizieren. Bisher hängt der dabei verwendete Hash an der Cipher Suite. Beim vorgeschlagenen XOF-Pfad tritt der 64 Oktett lange TranscriptHash der gewählten KDF an seine Stelle; Exporter-Werte und Finished-MAC folgen derselben Auswahl.

Die Bibliothek kennt diese Auswahl. Eine Anwendung, die den Authentifikator außerhalb der Bibliothek erstellt, kennt sie nicht zwangsläufig. Der Entwurf verlangt deshalb die KDF-Kennung oder eine eindeutige Nachricht, dass keine neue KDF ausgehandelt wurde. Hinzu kommt TLS oder DTLS, weil DTLS eine andere interne Plan-Kennung nutzt. TLS-Exporter(label, context, length) liefert Ableitungsmaterial, jedoch weder KDF-Entscheidung noch Protokollart. Wer nur die Bibliothek modernisiert, kann der Anwendung inkompatible Authentifikatoren hinterlassen.

Auch Sitzungs-Tickets und vorab geteilte Schlüssel müssen der KDF zugeordnet bleiben. Die dafür verwendeten Kennungen stammen aus RFC 9258. Zertifikatssignaturen sind ein anderer Vorgang: Ein XOF-Schlüsselplan beseitigt SHA-2 in einer Signatur oder Zertifikatskette nicht automatisch. Der Datatracker führt den Text als individuellen Entwurf im Zustand I-D Exists. Eine unabhängige öffentliche Interoperabilitätsprobe über die Bibliotheksgrenze fehlt in den geprüften Quellen; ein erfolgreich verifizierter Authentifikator unter XOF in TLS und DTLS würde diese Lücke schließen.