Die IETF TLS Working Group führt eine langwierige, teils hitzige Debatte darüber, ob draft-ietf-tls-mlkem veröffentlicht werden soll — eine Spezifikation, die reine ML-KEM-Codepoints für den TLS-1.3-Schlüsselaustausch registrieren würde. Der Entwurf durchlief einen Working Group Last Call, wurde zurückgewiesen, durchlief einen zweiten WGLC und ist immer noch ungeklärt. Der Mailinglistenthread umfasst über 70 Nachrichten. Forscher für formale Verifikation, ehemalige IETF-Vorsitzende und Ingenieure von Google, Akamai, Cloudflare, SandboxAQ und Zscaler haben sich geäußert.
Die Debatte wurde als Binärentscheidung dargestellt: hybrides PQC oder reines PQC. Diese Rahmung ist falsch, und die Evidenz im Thread selbst zeigt warum. Die Mailinglistendebatte findet in einem Vakuum der Deployment-Realität statt. Die Zahlen erzählen eine Geschichte, mit der keine Seite vollständig rechnet.
Was tatsächlich vorgeschlagen wird
Deirdre Connolly (SandboxAQ) hat den Entwurf verfasst. Er registriert drei reine ML-KEM-NamedGroup-Werte—MLKEM512 (0x0200), MLKEM768 (0x0201), MLKEM1024 (0x0202)—für TLS 1.3. Alle drei sind im IANA-Register als Recommended: N markiert. Der vorgesehene RFC-Status ist Informational, nicht Standards Track.
Vergleichen Sie dies mit den hybriden Codepoints, die bereits massiv in Produktion eingesetzt werden. X25519MLKEM768 (0x11EC) ist der Standard-Schlüsselaustausch in Chrome, Firefox und praktisch jedem PQC-fähigen TLS-Client, der heute ausgeliefert wird. Ein separater Entwurf von Muhammad Usama Sardar (TU Dresden) drängt darauf, die hybriden Codepoints auf Recommended: Y umzustellen.
Der Standardisierungsprozess kodiert eine klare Hierarchie: Hybrid ist empfohlen, rein ist verfügbar aber nicht empfohlen. Die Frage ist, ob „verfügbar aber nicht empfohlen“ überhaupt veröffentlicht werden sollte.
Die Gegenargumente
Nadim Kobeissi brachte das sichtbarste Argument gegen den Entwurf vor, sowohl auf der Mailingliste als auch auf LinkedIn, mit dem Argument, dass Hybridkonstruktionen kompositionelle Sicherheit bieten, die reines ML-KEM ohne greifbaren Nutzen verwirft. Aber die tiefergehenden technischen Einwände kamen von Beitragenden wie Joshua, der systematisch jede Motivation des überarbeiteten Entwurfs adressierte—regulatorische Rahmenbedingungen, kleinere Schlüsselgrößen, Einfachheit—und feststellte, dass keine davon die Bevorzugung von Standalone gegenüber Hybrid rechtfertigt. Der Schlüsselgrößen-Overhead für das Hinzufügen von X25519 zu ML-KEM-768 beträgt 2,9%. Der Unterschied bei den Taktzyklen liegt im Mikrosekundenbereich. „Wir werden irgendwann sowieso reines ML-KEM brauchen“ erklärt nicht, warum man jetzt den Sicherheitsgurt weglassen sollte. Und der überarbeitete Security-Considerations-Text, der die Einwände des ersten WGLC ausräumen sollte, wiederholte weitgehend den Zweck des Entwurfs, anstatt sich mit den Gegenargumenten auseinanderzusetzen.
Kobeissi formulierte es in politischen Begriffen—verglich die regulatorische Rechtfertigung mit Kasachstans Versuch von 2015, ein MITM-Root-Zertifikat zu installieren. Die technischen Einwender formulierten es in ingenieurstechnischen Begriffen: Die Motivationssektion des Entwurfs ist zirkulär, und keiner der genannten Vorteile hält einer Prüfung stand, wenn man sie gegen die kompositionelle Sicherheitsgarantie abwägt, die Hybrid bietet.
Die Befürworter
Die Antworten teilten sich in drei Richtungen.
Nick Sullivan machte den prozeduralen Punkt prägnant: Dies ist ein Informational-Dokument, das Codepoints mit Recommended: N registriert. Den WGLC so zu behandeln, als würde er reines ML-KEM für den Einsatz empfehlen, verwechselt zwei verschiedene Fragen—ob der Codepoint existieren sollte versus ob jemand ihn nutzen sollte.
Sophie Schmieg (Google) schrieb einen ganzen Beitrag, der Bedenken gegen ML-KEM entkräftet, und argumentierte, dass der praktische Effekt des reinen Codepoints ist, dass die NSA langsamere Handshakes bekommt. Alle anderen nutzen weiterhin den Hybrid. TLS hat Aushandlungsmechanismen; wenn eine Seite glaubt, ML-KEM sei allein nicht ausreichend sicher, handelt sie stattdessen den Hybrid aus.
Filippo Valsorda war direkter und unterstützte die Veröffentlichung „sowohl aus technischen Gründen als auch um den DoS auf die Ressourcen dieser WG zu beenden.“
Wo es gelandet ist
Benjamin Kaduk (Akamai, ehemaliger IESG Area Director) schnitt durch den Lärm mit einer strukturellen Beobachtung: Die TLS WG braucht eine konsistente Position über gleichzeitig veröffentlichte Dokumente hinweg. Man kann nicht einen Hybrid-Entwurf veröffentlichen, der sagt, Hybride seien generell bevorzugt, und gleichzeitig einen reinen Entwurf, der diese Präferenz nicht anerkennt. Die beiden Dokumente müssen kohärent sein.
Ilari Liusvaara schlug Formulierungen vor, die den entstehenden Konsens destillieren. Reine ML-KEM-Codepoints sollten existieren, aber der Entwurf sollte ein SHOULD use hybrid enthalten, mit drei Ausnahmen:
Erstens: Sie folgen einem Sicherheitsprofilstandard, der das Risiko akzeptiert—CNSA 2.0 ist der offensichtliche Fall.
Zweitens: Ein kryptographisch relevanter Quantencomputer hat traditionelle Kryptographie hinfällig gemacht—das ANSSI-Phase-3-Endspiel.
Drittens: Sie befinden sich in einer eingeschränkten Umgebung, in der der Hybrid-Overhead wirklich inakzeptabel ist—IoT-Geräte, bei denen jedes Byte zählt, und wo ein Bruch von ML-KEM bei weitem nicht das schlimmste Sicherheitsrisiko ist.
Kaduk befürwortete diese Richtung. Connolly begann mit der Ausarbeitung überarbeiteter Security-Considerations-Texte. Der Entwurfsstatus wechselte zu „Revised I-D Needed—Issue raised by WGLC.“
Was die Leitung tatsächlich zeigt
Auf der Client-Seite sieht die Adoption dramatisch aus. Cloudflare Radar meldet, dass über 60% des TLS-1.3-Traffics zu seinem Netzwerk jetzt Post-Quanten-Schlüsselvereinbarung umfasst, gestiegen von unter 3% Anfang 2024. Der Wendepunkt war Apples iOS-26-Release im September 2025, das hybrides PQC standardmäßig aktivierte. Vier Tage nach dem Launch stieg die PQ-Unterstützung von iOS-Geräten von unter 2% auf 11%. Bis Dezember nutzten über 25% der iOS-Anfragen Post-Quanten-Verschlüsselung. Chrome und Firefox waren bereits dort. Der Browser-Auto-Update-Zyklus schaffte, was Jahre der Standards-Advocacy nicht konnten.
Jede einzelne dieser Verbindungen handelt X25519MLKEM768 aus—den Hybrid. Null reines ML-KEM. Das ist keine Wahl; es ist die einzige Option, die existiert.
Schauen wir nun auf die Origin-Seite, wo das Harvest-Now-Decrypt-Later-Risiko tatsächlich liegt. Cloudflares automatisierter TLS-Scanner, gestartet im Februar 2026, meldet, dass etwa 10% der Kunden-Origin-Server X25519MLKEM768 unterstützen. Das ist eine Verzehnfachung gegenüber unter 1% Anfang 2025, hauptsächlich getrieben durch Bibliotheks-Defaults—Go 1.24+, OpenSSL 3.5.0+ und GnuTLS 3.8.9+ aktivierten alle standardmäßig hybrides PQC. TLS-Bibliothek aktualisieren, PQC gratis bekommen. Aber 10% sind immer noch 10%. Neunzig Prozent der Origin-Server handeln null Post-Quanten-Schlüsselaustausch aus.
Das ist die Lücke, die zählt. Die 60%-Client-Seite-Zahl misst Browser-Marktanteil, nicht Sicherheitslage. Ein Chrome-Nutzer, der sich mit X25519MLKEM768 zu Cloudflares Edge verbindet, bekommt hybrides PQC für die letzte Meile—aber wenn Cloudflares Abruf zum Origin auf X25519 zurückfällt, ist der vollständige Pfad nicht geschützt. Der Traffic, den Cloudflare als „post-quantum“ meldet, ist post-quantum bis zur Edge. Die Origin-Verbindung—die, die die eigentlichen Anwendungsdaten durch Infrastruktur transportiert, die Sie kontrollieren—ist in 90% der Fälle klassisch.
Das ist es, was pqprobe scannt. Nicht die Edge. Den Origin. Nicht die Fähigkeit des Browsers. Die des Servers. Und nicht nur TLS auf Port 443—pqprobe prüft 20+ Protokolle über 60+ Port-Variationen: SSH, SMTP, IMAP, RDP, Datenbankprotokolle, Kafka, Healthcare-Protokolle. Die Angriffsfläche für Harvest-Now-Decrypt-Later erstreckt sich über jeden verschlüsselten Kanal, den eine Organisation betreibt. Ein Server mit hybridem TLS auf Port 443 und klassischem SSH auf Port 22 hat eine partielle Migration, und eine partielle Migration ist eine messbare Trajektorie.
Auf der Authentifizierungsseite ist das Bild noch deutlicher. Null PQC-Zertifikate werden in Produktions-TLS ausgeliefert. Keine Zertifizierungsstelle hat bisher ML-DSA-Zertifikate ausgestellt—Cloudflares eigenes Team erwartet die früheste CA-Ausstellung um 2026, mit breiterer Adoption frühestens 2027, gebremst durch HSM-Hardware-Unterstützung, FIPS-Audits und CA/Browser-Forum-Genehmigung. Der Reddy/Wing-Migrationsleitfaden-Entwurf beschreibt drei Pfade für die Authentifizierung—Composite-Zertifikate, Dual-Zertifikate, PQC-only—und jeder Pfad führt zu reinem PQC als Endpunkt. Aber Reddys Abschnitt 9.3 erklärt, warum Hybrid architektonisch temporär ist: Sobald die traditionelle Komponente bricht, verliert man Strong Unforgeability. Hybridmechanismen degradieren und müssen schließlich abgelöst werden.
Das vollständige Bild ist also: Schlüsselaustausch ist teilweise auf Hybrid an der Edge migriert, kaum am Origin, und null auf rein migriert. Authentifizierung hat nicht begonnen. Die Rein-vs-Hybrid-Debatte auf der Mailingliste dreht sich um den Endzustand einer Migration, die der Großteil des Internets noch nicht begonnen hat.
Die falsche Binärentscheidung
Die eigentliche Frage war nie „hybrid oder rein.“ Sie war „wo befinden Sie sich auf der Migrationskurve, und ist Ihre Trajektorie korrekt?“ Die IETF beantwortet dies, indem sie sowohl hybride als auch reine Spezifikationen veröffentlicht, hybrid als empfohlen und rein als verfügbar-aber-noch-nicht markiert, und vom reinen Entwurf verlangt, explizit auf hybrid als aktuellen Standard zu verweisen.
Das ist die IETF, die die Straße baut, bevor der Verkehr sie braucht. Klingt normal, oder? Wenn Sie das als Schwächung sehen, lassen Sie uns darüber reden, warum.
Die Kasachstan-Analogie bricht unter dieser Rahmung zusammen. Kasachstan wollte TLS-Traffic abfangen. CNSA 2.0 will den Algorithmus nutzen, auf den sich alle als Ziel einig sind, ohne darauf zu warten, dass der Rest des Ökosystems aufholt. Man kann mit dem Vertrauen der NSA in Gittermathematik nicht einverstanden sein, ohne deren Zeitplan als Angriff auf das Protokoll zu behandeln.
Ein Codepoint im Register schwächt Ihre Verbindung nicht mehr, als die Existenz von TLS_RSA_WITH_RC4_128_SHA Sie zwingt, RC4 auszuhandeln. TLS hat einen Aushandlungsmechanismus. Wenn Sie reinem ML-KEM nicht vertrauen, bieten Sie es nicht an.
Unterdessen handeln neunzig Prozent der Origin-Server immer noch null PQC-Schlüsselaustausch aus. PQC-Authentifizierung hat nicht begonnen. Die Mailingliste diskutiert, ob die Ausfahrt gebaut werden soll, während der Großteil des Traffics die Auffahrt noch nicht gefunden hat. Die Hybrid-vs-Rein-Debatte dreht sich um das 2035-Ziel. Die meisten Organisationen haben die 2027-Startlinie nicht erreicht.