Der überstürzte Weg zu Post-Quantum-TLS: Eine Kritische Analyse des IETF-Standardisierungsprozesses

Hintergrund: Was ist ML-KEM und warum ist es relevant?

Mit der zunehmenden Bedrohung durch Quantencomputer hat die Kryptographie-Community in den letzten Jahren intensiv an sogenannten Post-Quantum-Kryptosystemen (PQC) gearbeitet – Algorithmen, die auch gegenüber Angriffen durch Quantencomputer sicher sind. Das NIST hat 2024 mit ML-KEM (Module-Lattice-based Key Encapsulation Mechanism, standardisiert als FIPS 203, auch bekannt unter dem Projektnamen CRYSTALS-Kyber) einen der ersten offiziellen PQC-Standards veröffentlicht.

Parallel dazu arbeitet die IETF TLS Working Group daran, ML-KEM in TLS zu integrieren – dem Protokoll, das die Sicherheit des größten Teils des verschlüsselten Internetverkehrs gewährleistet. 

Genau hier beginnt die Kontroverse.

Der aktuelle Konflikt: Hybrid vs. reines PQC

Im Kern der Debatte steht eine grundlegende Sicherheitsentscheidung:

Hybride Verfahren kombinieren klassische Algorithmen (z. B. ECDH mit P-256 oder X25519) mit einem PQC-Verfahren wie ML-KEM. Das bedeutet: Ein Angreifer müsste beide Verfahren gleichzeitig brechen, um die Kommunikation zu kompromittieren.

Reine PQC-Verfahren (engl. pure oder standalone PQC) verzichten vollständig auf den klassischen Anteil und verlassen sich ausschließlich auf ML-KEM. Dies ist der Ansatz des strittigen Drafts draft-ietf-tls-mlkem. - siehe https://datatracker.ietf.org/doc/draft-ietf-tls-mlkem/

Die Frage ist nicht akademischer Natur: Sollte sich ML-KEM in der Praxis als verwundbar erweisen, sei es durch mathematische Schwächen, Implementierungsfehler oder zukünftige Angriffe, dann bietet ein hybrides Verfahren immer noch den Schutz des klassischen Algorithmus. Ein reines PQC-Verfahren hingegen fällt komplett.

Die Beschwerde von D. J. Bernstein: Ein Protokollversagen in drei Akten

Am 20. Februar 2026 reichte Daniel J. Bernstein, einer der profiliertesten Kryptographen der Welt und Autor von Algorithmen wie Curve25519 und ChaCha20, eine formale Beschwerde gemäß RFC 2026, Section 6.5.1, gegen die TLS Working Group Chairs ein. Die Beschwerde dokumentiert drei voneinander unabhängige, aber sich gegenseitig verstärkende Verfahrensfehler.

Problem 1: Unzulässiger zweiter Working Group Last Call

Im November 2025 durchlief draft-ietf-tls-mlkem-05 einen regulären Working Group Last Call (WGLC) – das formale Verfahren, mit dem die WG prüft, ob Konsens zur Veröffentlichung eines Drafts besteht. Das Ergebnis war eindeutig: Mindestens acht WG-Teilnehmer erhoben substanzielle Einwände, darunter namhafte Experten wie Benjamin Kaduk (ehemaliger IETF Security Area Director), Watson Ladd, Simon Josefsson und Stephen Farrell. Die Chairs selbst konstatierten korrekt: "we do not have consensus to publish the document as is."

Drei Monate später, im Februar 2026, initiieren dieselben Chairs einen zweiten WGLC für draft-ietf-tls-mlkem-07. Das Problem: Die Überarbeitungen von -05 zu -07 sind minimal. Die Motivation beschränkt sich weiterhin auf einen einzigen kurzen Absatz. Es fehlt nach wie vor jede konkrete Referenz auf die behaupteten regulatorischen Anforderungen, die angeblich ein reines PQC-Verfahren erzwingen. Das zentrale Sicherheitsargument – warum ein unnötiges Sicherheitsrisiko eingegangen werden soll – bleibt vollständig unbeantwortet.

Ein zweiter WGLC ist an sich nicht illegitim. Das Problem liegt in der impliziten Botschaft: Ein neuer Last Call signalisiert, dass die früheren Einwände adressiert wurden. Das ist hier schlicht falsch.

Problem 2: Einschränkung des Konsensbildungsprozesses

Der zweite WGLC enthielt die Formulierung: "The main focus of this WGLC is to review new text providing more context around the use of pure ML-KEM." Isoliert betrachtet mag das harmlos klingen – doch der zuständige Area Director Paul Wouters verschärfte diese Einschränkung in einer späteren Nachricht erheblich, indem er das Ziel des zweiten WGLC ausdrücklich auf die Beurteilung des neuen Textes begrenzte.

Die Konsequenz: WG-Teilnehmer, die grundsätzliche Einwände gegen das reine PQC-Konzept haben – also gegen den Kern des Dokuments –, werden faktisch entmutigt, diese erneut vorzubringen. Das korrumpiert die Konsensbildung: Konsens kann nicht festgestellt werden, wenn Teile des Meinungsbildes systematisch ausgeblendet werden.

Trotz dieser Einschränkung meldeten sich erneut acht oder mehr Teilnehmer mit klaren Einwänden zu Wort, darunter neue Stimmen wie Izzy Grosof und Nadim Kobeissi.

Problem 3: Nachträgliche Umdeutung eines gescheiterten WGLC

Besonders gravierend ist die dritte Problematik: AD Wouters behauptete in seiner Nachricht, der erste WGLC vom November 2025 habe bestanden – und zwar unter der Bedingung, dass ein klärender Text zur Bevorzugung hybrider Verfahren im Allgemeinfall hinzugefügt werde. Diese Darstellung widerspricht diametral der offiziellen Zusammenfassung der Chairs, die unmissverständlich das Fehlen von Konsens festgestellt hatten.

Dieses Vorgehen verstößt gegen ein fundamentales Prinzip des IETF-Prozesses: Man kann keinen Konsens für Maßnahme X feststellen und diesen nachträglich in Konsens für Maßnahme Y umdeuten, ohne eine erneute Konsultation der WG. Die Legitimität des gesamten Verfahrens hängt davon ab, dass Entscheidungen transparent kommuniziert und nicht im Nachhinein reinterpretiert werden.

Technische Analyse: Warum die Kritiker Recht haben

Die Einwände gegen draft-ietf-tls-mlkem sind nicht bürokratischer Natur – sie sind technisch fundiert.

ML-KEM ist jung und unzureichend analysiert

Obwohl das NIST-Standardisierungsverfahren gründlich war, ist ML-KEM deutlich jünger als etablierte Verfahren wie ECDH. Die Crypto-Community hat noch nicht die gleiche Menge an Analyse-Zeit und -Ressourcen investiert. In der Geschichte der Kryptographie haben auch sorgfältig analysierte Algorithmen nach Jahren noch Schwächen offenbart.

Hybride Verfahren sind bereits verfügbar und ausreichend

X25519MLKEM768 mag noch nicht offiziell standardisiert sein, ist aber dennoch bereits großflächig Einsatz. Es bietet denselben Quantenschutz wie ein reines ML-KEM, fügt aber eine robuste Rückfallebene hinzu. Es gibt keinen erkennbaren Nachteil hybrider Verfahren gegenüber reinen PQC-Verfahren in TLS – der Overhead ist minimal und vertretbar.

Die behauptete regulatorische Notwendigkeit ist nicht belegt

Die einzige Rechtfertigung für ein reines PQC-Verfahren wären Regulierungen, die explizit klassische Algorithmen verbieten. Solche Regulierungen existieren derzeit nicht in nennenswertem Umfang, und das Dokument nennt keine einzige konkrete Referenz. Diese Lücke ist ein zentraler Kritikpunkt, der durch die Überarbeitungen nicht geschlossen wurde.

Das Prinzip der minimalen Angriffsfläche

Gutes Security-Engineering folgt dem Grundsatz, unnötige Risiken zu vermeiden. Ein reines PQC-TLS zu standardisieren, während hybride Verfahren dieselben Ziele mit höherer Sicherheitsmarge erfüllen, widerspricht diesem Prinzip fundamental. Es ist nicht die Aufgabe eines Standards, unnötige Experimente mit dem Sicherheitsniveau zu machen.

Die Systemfrage: Vertrauenswürdigkeit des IETF-Prozesses

Was diese Beschwerde besonders bedeutsam macht, ist ihr Blick über das konkrete Dokument hinaus. Bernstein und die anderen Kritiker stellen implizit eine größere Frage: Kann der IETF-Prozess als vertrauenswürdig gelten, wenn Verfahrensfehler dieser Art möglich sind?

Die IETF lebt vom Prinzip des rough consensus – nicht von formalen Abstimmungen, sondern von sorgfältiger Abwägung der technischen Argumente aller Beteiligten. Dieser Prozess funktioniert nur, wenn die Chairs und Area Directors neutral moderieren und die Regeln konsistent anwenden. Wenn jedoch Einwände ignoriert, WGLC-Ergebnisse umdefiniert und der Diskursraum eingeschränkt wird, untergräbt das das Fundament, auf dem die Autorität von IETF-Standards beruht.

Ein Standard, der durch ein beschädigtes Verfahren verabschiedet wird, hat ein Legitimationsproblem – unabhängig von seinen technischen Meriten oder Schwächen.

Dieser Artikel basiert auf der Beschwerde von D. J. Bernstein vom 20. Februar 2026 sowie öffentlich zugänglichen Diskussionen auf der IETF TLS Working Group Mailing List.

Die darin enthaltenen Einschätzungen spiegeln die Analyse von White Rabbit Security wider.

Links:

https://mailarchive.ietf.org/arch/msg/ietf/PStIAGIP2gbTNUPrr3t2jUjnS6g/

https://mailarchive.ietf.org/arch/browse/tls/?gbt=1&index=USZ5L3z4g667iV4L5ZiuTcQGijI