Zusammenfassung

  • RFC 9973 kombiniert einen extern provisionierten PSK und ein (EC)DHE-Geheimnis im TLS-1.3-Schlüsselschema, ohne die Zertifikatsauthentisierung zu ersetzen.
  • Ausgewählte PSK-Identität und Binder belegen die gemeinsame Zuordnung eines Geheimwerts in diesem Handshake. Sie belegen weder Herkunft noch alleinige Verwahrung noch nachgelagerte Berechtigung.
  • Eine belastbare Kontrolle hält Geheimnislebenslauf, TLS-Aushandlung, Zertifikatsentscheidung, Anwendungsfreigabe, Commit und beobachtete Wirkung getrennt und verknüpft sie anschließend.

Ein Versorger übernimmt eine Flotte von Feldgeräten. In der Übergabedatei steht für jedes Gerät eine Zertifikatsreferenz und eine externe PSK-Kennung. Die technische Abnahme testet den Verbindungsaufbau und meldet Erfolg. Für die Sicherheitsfreigabe beginnt die Arbeit erst dort: Wer kann die PSK noch lesen? Wurde sie einmalig für dieses Gerät abgeleitet oder in einer Geräteklasse wiederverwendet? Darf der so authentisierte Endpunkt nur aufgenommen werden oder auch Betriebsparameter ändern?

Die RFC 9973 beantwortet den gemeinsamen Drahtteil. Die Standards-Track-RFC aus Juli 2026 ersetzt RFC 8773 und definiert tls_cert_with_extern_psk. Bei erfolgreicher Aushandlung gehen der gewählte externe PSK und das (EC)DHE-Shared-Secret in den TLS-1.3-Key-Schedule ein. Die Authentisierung beruht weiterhin auf Signaturen, die mit den öffentlichen Schlüsseln der Zertifikate validiert werden. Ein aus einer früheren Verbindung stammender resumption PSK ist ausdrücklich nicht dasselbe wie ein auf anderem Weg bereitgestellter external PSK.

Der Client muss die Erweiterung mit key_share, supported_groups, psk_key_exchange_modes und pre_shared_key senden und darf sie nicht mit early_data verbinden. Für den ersten Handshake ist psk_dhe_ke vorgeschrieben; die Liste darf nur externe PSKs enthalten. Der Server sendet die Erweiterung nur, wenn er einen angebotenen externen PSK verwenden und zugleich zertifikatsbasiert authentisieren will. Die IANA-Registrierung führt dafür ExtensionType 33. Ein registrierter Name sagt nichts über die Fähigkeit eines bestimmten Geräts oder Dienstes.

Protokollkonsens ist keine Schlüsselbiografie

Der Server wählt einen Eintrag aus der Identitätsliste. Der passende Binder ist über HMAC und einen Teil des Handshake-Transcripts an den PSK gebunden. Seine Prüfung zeigt: Für diese Ausführung haben Client und Server dem gewählten Eintrag denselben Wert zugeordnet. Sie zeigt nicht, ob ein bestimmter Lieferant den Wert korrekt generierte, ob ein Backup ihn kopierte, ob ein ausgeschiedener Dienstleister ihn behielt oder ob der Wert für eine andere Funktion zweckentfremdet wird.

Genau diese Lücke ist der Grund, warum RFC 9973 Erzeugung, Verteilung und Verwaltung externer PSKs ausklammert. Zugleich macht sie die Schutzbehauptung davon abhängig, dass der PSK vertraulich, entropiereich und authentisch bleibt. Sie fordert sichere Schlüsselverwaltung und warnt vor schwachen Zufallsquellen. RFC 4086 beschreibt Anforderungen an Zufall, aber keine konkrete Fertigungsstraße.

Auch die Authentisierung bleibt getrennt. Ein externer PSK darf nicht die alleinige Authentisierungsbasis sein. Der PSK kann unter den genannten Annahmen eine zusätzliche Vertraulichkeitsbedingung liefern, wenn künftig (EC)DH gebrochen würde und der Angreifer den PSK nicht kennt. Er löst nicht automatisch das zukünftige Problem der Zertifikatssignatur. RFC 9958 beschreibt den Kontext, nicht den Reifegrad einer Flotte.

Besonders leicht übersehen wird die Wiederverwendung. Ein nur für eine Sitzung und zwei Parteien bekannter PSK hat andere Eigenschaften als ein gruppenbekannter oder über viele Sitzungen verwendeter Wert. PSK-Identitäten erscheinen im Klartext-ClientHello und können Verbindungen korrelierbar machen. Rotation und Encrypted Client Hello sind mögliche Gegenmaßnahmen, ersetzen aber keine Zweck- und Verwahrungsentscheidung.

Getrennte Belege für getrennte Macht

Der Schlüsselverantwortliche sollte Zweck, Erzeugungs- oder Ableitungsart, zulässige Peer-Menge, Protokoll- und Hash-Grenze, Verteilweg, Verwahrer, Wiederverwendungsgrenze, Rotation und Löschung dokumentieren. Der Geheimwert gehört nicht in das Prüfprotokoll; sichere Referenzen und Ereignisbelege reichen aus. Das TLS-Protokoll ergänzt Angebot und Annahme der Erweiterung, sicheren Bezug zur gewählten Identität, psk_dhe_ke, Zertifikatsvalidierung und Finished- oder Alert-Ergebnis.

Danach folgt ein anderes Protokoll: Welche Anwendungsrichtlinie gab diesem Peer die Berechtigung? Welche Frische- und Replay-Regel galt? Wurde die Änderung dauerhaft geschrieben, und welcher unabhängige Messpunkt sah ihre Wirkung? Heng Lus Running-Code-Primacy verlangt genau diese Trennung. Ein Inventar besagt, was vorgesehen war; nur die ausgeführte, zugeordnete Kette zeigt, was tatsächlich entschied. Formale Schlüsselzuordnung ist kein Ersatz für praktische Zugriffsmacht.

Quellen