> (2) The RFC at issue documents the possibility of running TLS with pure MLKEM rather than in a hybrid configuration with ECDH. Hybrid TLS is already the mainstream, documented, standardized method for using PQC in a TLS connection. Bernstein is canvassing opposition to any documentation of the possibility of pure MLKEM in TLS.
Two more pieces of context here: 1. The IETF allows code point registrations based purely on the existence of a specification, and the pure ML-KEM code points have already been assigned (https://www.iana.org/assignments/tls-parameters/tls-paramete...). The question at hand is whether the IETF will publish an RFC documenting the ML-KEM cipher suites [edited to make clear that ML-KEM is documented already].
2. It is also possible to publish an RFC via what's called "Independent Submission" (https://www.rfc-editor.org/authors/rfc-independent-submissio...), which is not subject to the IETF Consensus process. This is, for instance, how the GOST RFC (https://datatracker.ietf.org/doc/rfc9367/) was published. If the IETF opts not to publish this draft, the authors can still submit it to the Independent Submissions Editor.
> The question at hand is whether the IETF will publish an RFC documenting the ML-KEM.
The IETF document only documents how and where to put the MLKEM values into TLS. MLKEM itself is specified in FIPS203 and it just references that for the actual cryptographic details. The IETF document is in fact quite short:
https://www.ietf.org/archive/id/draft-ietf-tls-mlkem-08.html
(This doesn't mean the document is a stub or pointless or something like that, you do need a "what goes where".)
The ISE has said they aren't progressing crypto drafts anymore.
> https://www.iana.org/assignments/tls-parameters/tls-paramete...
Further the draft that this is all about does not make a recommendation for its use. The currently IETF-recommended TLS algorithms are: X25519MLKEM768, x448, x25519, secp384r1, secp256r1.
As noted by someone on the IETF list [1] there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document. No one is forcing anyone to use this algorithm, and it's not even 'officially' recommended (per above).
[1] https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...