Zusammenfassung

  • Am 3. September 2026 genehmigte die IESG Revision 10 von ML-KEM Post-Quantum Key Agreement for TLS 1.3 zur Veröffentlichung als Informational RFC. Im geprüften Stand war noch keine RFC-Nummer vergeben.
  • MLKEM512, MLKEM768 und MLKEM1024 erhalten TLS-NamedGroup-Werte mit DTLS-OK=Y und Recommended=N. Nach RFC 9847 ist N weder Empfehlung noch Abraten oder Fehlerurteil.

Ein Change-Ticket mit dem Satz „IETF approved“ kann erstaunlich schnell zu einer flottenweiten Standardeinstellung werden. Dasselbe Ticket könnte wegen Recommended=N pauschal abgelehnt werden. Beide Entscheidungen wären schneller als die Beweisführung und beide würden den Registereintrag falsch lesen.

Revision 10 beschreibt zunächst einen vollständigen Austausch. KeyGen erzeugt öffentlichen Kapselungsschlüssel und geheimen Entkapselungsschlüssel. Der Client sendet den öffentlichen Schlüssel als key_share. Der Server erzeugt mit Encaps Ciphertext und gemeinsames Geheimnis und sendet den Ciphertext zurück. Der Client gewinnt mit Decaps dasselbe 32-Byte-Geheimnis, das in den TLS-1.3-Schlüsselplan eingeht.

Die Werte 512, 513 und 514 stehen für MLKEM512, MLKEM768 und MLKEM1024. Öffentliche Schlüssel messen 800, 1.184 und 1.568 Byte; Ciphertexts 768, 1.088 und 1.568 Byte. Daraus folgt keine gemessene Latenz, Fragmentierung oder Plattformkapazität.

Der Server muss die Kapselungsschlüsselprüfung aus FIPS 203 ausführen und bei Fehler mit illegal_parameter abbrechen. Der Client prüft die Ciphertext-Länge für den gewählten Parametersatz. Andere Entkapselungsfehler ergeben internal_error. Der Transcript bindet die Key-Share-Felder in den Handshake ein.

Die Implementierung bleibt ein eigener Nachweis. Zufall für die Ciphertext-Erzeugung und damit Ciphertexts dürfen nicht wiederverwendet werden. Der Inhaber des Entkapselungsschlüssels erhält den Kapselungszufall exakt zurück. Bei einem unsicheren RNG können dadurch Zusammenhänge mit weiteren Ausgaben oder dem Generatorzustand sichtbar werden. FIPS 203, NIST SP 800-227 und RFC 8937 sind Vorgaben und Anleitung, keine Bescheinigung für ein konkretes Binary.

Am 5. September enthielt die lebende IANA-Tabelle bereits alle drei Werte. Ihre Referenz zeigte noch auf Revision 05 des früheren Individual Drafts, während Datatracker Revision 10 als genehmigt und die IANA-Aktion als laufend auswies. Dieser Zwischenstand braucht einen Zeitstempel; er ist weder dauerhafte Wahrheit noch automatisch ein Fehler.

RFC 9847 definiert Y als IETF-Konsens über die Eignung für den beschriebenen Zweck, D als begründetes Abraten und N als fehlende IETF-Aussage zur Eignung. N kann begrenzte Anwendbarkeit, Nutzungsbedingungen oder fehlenden Konsens ausdrücken und bedeutet nicht zwingend einen Mangel.

Auch DTLS-OK=Y ist keine versteckte Empfehlung. Es beantwortet die DTLS-Dimension des Eintrags. Es prüft weder Library, Zufallsquelle, Netzpfad noch Anwendung. Eine Ampel, die beide Spalten in Grün zusammenfasst, erfindet Autorität.

RFC 10024 zeigt den Unterschied zu hybriden Gruppen. X25519MLKEM768 trägt derzeit Recommended=Y, andere hybride Gruppen N. Das eigenständige ML-KEM-Dokument überlässt die Wahl ausdrücklich einer Bewertung von Sicherheits-, Leistungs- und Betriebsanforderungen.

Ein belastbarer Rollout braucht getrennte Belege: genehmigte Revision, IANA-Snapshot, Library- und Modul-Build, RNG- und Fork-Verhalten, Konfiguration an jedem Terminator, Client-Angebot, Server-Auswahl, Prüffehler, abgeschlossenen Handshake und Anwendungstransaktion. Kein Beleg darf die nächste Stufe vertreten.

Lu Hengs Running-Code-Prinzip schützt hier den Standard vor Überdehnung. Eine minimale gemeinsame Spezifikation koordiniert Nummern, Bytes und Fehler. Die lokale Organisation autorisiert das Risiko. Realitätsebenen halten Veröffentlichung, Registrierung, Empfehlung und Ergebnis auseinander.

Die IESG hat einen Mechanismus veröffentlichungsreif gemacht. IANA macht ihn adressierbar. Das N lässt die Eignungsentscheidung bewusst offen. Der Betreiber muss sie mit eigener Evidenz schließen, nicht mit geliehener Symbolkraft.

Quellen