Zusammenfassung

  • RFC 10024 definiert X25519MLKEM768, SecP256r1MLKEM768 und SecP384r1MLKEM1024 als TLS-1.3-Gruppen, die ML-KEM mit einer traditionellen elliptischen Komponente zur Schlüsselvereinbarung kombinieren.
  • Der Sitzungsschlüssel und die Authentifizierung des Servers sind unterschiedliche Ergebnisse. Eine hybride Gruppe ersetzt weder die Zertifikatskette noch die CertificateVerify-Signatur automatisch.
  • Bas Westerbaan verfasste die RFC gemeinsam mit Krzysztof Kwiatkowski, Panos Kampanakis und Douglas Stebila. Der Standard liefert einen prüfbaren Migrationsschritt, kein Gesamturteil über einen Dienst.

In einem TLS-Bericht können zwei scheinbar unvereinbare Befunde nebeneinanderstehen: Die Verbindung handelte X25519MLKEM768 aus. Der Server authentifizierte sich mit einer klassischen Signatur. Technisch ist das kein Widerspruch, sondern eine saubere Arbeitsteilung im Protokoll.

RFC 10024 wurde im August 2026 als IETF Proposed Standard veröffentlicht. Sie weist drei Kombinationen feste TLS-1.3-Gruppen zu: X25519 plus ML-KEM-768, secp256r1 plus ML-KEM-768 und secp384r1 plus ML-KEM-1024. Client und Server übermitteln die Anteile beider Komponenten und bilden daraus nach den vorgegebenen Regeln ein gemeinsames Geheimnis.

Der zeitliche Gegner erklärt den Zweck. Ein passiver Sammler kann verschlüsselten Verkehr heute speichern und darauf hoffen, die klassische Schlüsselvereinbarung mit einem künftigen kryptografisch relevanten Quantencomputer zu brechen. Die PQ/T-Konstruktion soll verhindern, dass das Sitzungsgeheimnis ausschließlich von der traditionellen oder ausschließlich von der neuen Post-Quanten-Komponente abhängt.

Damit ändert sich eine wesentliche Risikoeigenschaft. Die benachbarten Eigenschaften ändern sich nicht durch Ansteckung.

Zertifikate beantworten eine andere Frage

TLS 1.3 führt mehrere kryptografische Aufgaben in einem Handshake zusammen. Das Ergebnis des Schlüsselaustauschs fließt in den Schlüsselplan und erzeugt Material für die Verkehrsverschlüsselung. Zertifikatskette und CertificateVerify-Signatur dienen dagegen dazu, den Server zu authentifizieren.

Die erste Prüfung fragt, wie beide Endpunkte ihre Verbindungsgeheimnisse gebildet haben. Die zweite fragt, ob der behauptete Endpunkt den privaten Schlüssel eines vertrauenswürdigen Zertifikats kontrolliert und das Handshake-Transkript mit einem zugelassenen Signaturverfahren bestätigt hat. Ein gemeinsames Transkript macht die Antworten nicht identisch.

RFC 9794 legt dafür eine hilfreiche Sprache fest. PQ/T-hybride Schlüsselherstellung, hybride KEMs, hybride Public-Key-Verschlüsselung und hybride digitale Signaturen sind getrennte Familien. Sie können zu unterschiedlichen Zeiten standardisiert und eingesetzt werden. Auch RFC 9935, die X.509-Kennungen für ML-KEM-Schlüssel definiert, ist kein Beleg für eine ausgestellte Vertrauenskette. ML-KEM ist zudem nicht plötzlich ein Signaturalgorithmus.

Der passive Gegner, der aufgezeichnete Sitzungen später lesen will, wird durch die hybride Schlüsselvereinbarung adressiert. Ein künftiger aktiver Gegner, der eine klassische Zertifikatssignatur fälscht und einen Server imitiert, verlangt eine Migration von Signaturen, Zertifikaten, Ausstellung und Prüfung. Beide Szenarien gehören zur Quantenrisikoplanung, aber nicht in dasselbe Kontrollkästchen.

Stufenweise Migration als belastbarer Befund

Cloudflare Research beschreibt Bas Westerbaan als Research Engineer, der die Verbreitung von Post-Quanten-Kryptografie von Engineering und Standardisierung über Großversuche bis zur Einführung vorantreibt. Sein IETF-Datensatz enthält RFC 10024 und weitere Arbeiten auf diesem Gebiet.

Die kollektive Urheberschaft bleibt wesentlich. Krzysztof Kwiatkowski, Panos Kampanakis und Douglas Stebila sind Mitautoren. Die RFC stützt sich auf die allgemeine Hybridkonstruktion in RFC 9954, die Terminologie aus RFC 9794, TLS 1.3 und NISTs ML-KEM-Standard. Westerbaans Profil verbindet diese Ebenen, ersetzt aber nicht die Beiträge des Teams.

Eine Cloudflare-Veröffentlichung vom September 2025 zeigt die Grenze praktisch. Mehr als ein Drittel des menschlich erzeugten Verkehrs zum eigenen Netz nutzte demnach TLS 1.3 mit hybrider Post-Quanten-Schlüsselvereinbarung. Im selben Text erklärte das Unternehmen, Post-Quanten-Signaturen und -Zertifikate würden für TLS und die Internet-PKI noch standardisiert; WARP sei damals noch nicht darauf umgestellt gewesen.

Die Zahl ist eine datierte Beobachtung im Cloudflare-Netz, keine globale Quote und keine Bestätigung aller späteren Konfigurationen. Trotzdem ist sie wertvoll: Großflächige Einführung einer Komponente kann mit einer noch klassischen Authentifizierung koexistieren. Eine gestufte Migration ist normal. Unpräzise ist erst das Etikett, das die Stufen verschweigt.

Was der Aushandlungsnachweis trägt

Ein Eintrag in supported_groups zeigt Fähigkeit oder Präferenz des Clients, nicht die endgültige Auswahl. Wählt der Server eine RFC-10024-Gruppe, ist die Vereinbarung am sichtbaren Endpunkt belegt. Implementierungsfehler, schwacher Zufall, Seitenkanäle oder verborgene Rückfälle bleiben außerhalb dieses Befunds.

Ein abgeschlossener Handshake zeigt zusätzlich, dass die Endpunkte nutzbare Verkehrsgeheimnisse hergestellt haben. Für die Authentifizierung müssen Zertifikatskette und Signaturverfahren erfasst werden. Für die Architektur zählen TLS-Terminator, Reverse Proxy, Origin-Verbindung, Session-Wiederaufnahme, 0-RTT, Tunnel und interne Servicepfade.

Nach der Entschlüsselung wandern Daten in andere Kontrollbereiche. Protokolle, Datenbanken, Warteschlangen und Sicherungen können eigene Schlüssel oder gar Klartext verwenden. Zertifikatswiderruf, Session-Tickets, Anwendungsgeheimnisse und Wiederherstellung gespeicherter Daten lassen sich nicht aus dem Gruppennamen ablesen.

RFC 10024 warnt zudem davor, eine ähnliche Hybridisierung in anderen Protokollen ohne eigene Analyse als sicher anzusehen. Kombinator, Reihenfolge, Längen, Transkript und Bedrohungsmodell gehören zum Sicherheitsargument. Zwei nebeneinander gesetzte Algorithmen ergeben noch keinen sicheren Standard.

RFC 9851 friert neue Funktionen für TLS 1.2 ein und lenkt Innovation zu TLS 1.3. Das ist eine wichtige Richtungsentscheidung, synchronisiert aber nicht Zertifikate, Kryptobibliotheken, Hardware, Proxys und Datenspeicher.

Vom Produktwort zum Betriebsbeleg

Heng Lus Prinzip des Vorrangs laufenden Codes liefert die passende Prüfung: Eine Behauptung ist nicht das Betriebsergebnis. Ein belastbarer Nachweis muss die Beobachtung wiederholbar machen.

Dazu gehören Client, Endpunkt, Zeit, TLS-Version, angebotene und ausgewählte Gruppen, Implementierungsversion, Zertifikatskette, CertificateVerify-Signatur, Terminierungsort, Wiederaufnahme, Schutz nachgelagerter Verbindungen und die Stelle, an der Klartext entsteht. Auch Messmethode und blinde Flecken gehören in den Beleg.

Die Felder verteilen Verantwortung. Die IETF spezifiziert. Browser und Bibliotheken implementieren. Betreiber konfigurieren. Zertifizierungsstellen stellen aus. Netzteams betreiben Proxys. Anwendungen speichern. Incident-Teams widerrufen und stellen wieder her. Ein erfolgreicher Handshake erledigt nicht die Arbeit aller Eigentümer.

RFC 10024 macht einen entscheidenden Schritt benennbar, aushandelbar und überprüfbar. Eine reife Migration würdigt genau diesen Fortschritt und hält Zertifikat, Signatur und Datenpfad weiterhin offen im Register.

Quellen