18 ms·

> (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 mains

by ekr____ 2mo ago

> (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-parameters.xhtml#tls-parameters-8 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-submissions/ 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/ 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.

wbl 2mo ago
The ISE has said they aren't progressing crypto drafts anymore.
eqvinox 2mo ago
> 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 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".)
- ekr____ 2mo ago
  You're right. Bad writing on my part. Edited to make it clear.
throw0101d 2mo ago
> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 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_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...
- chrismorgan 2mo ago
  > there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t. (There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.) This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.
  - tptacek 2mo ago
    These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.

by ekr____ 2mo ago

wbl 2mo ago

The ISE has said they aren't progressing crypto drafts anymore.

eqvinox 2mo ago

> 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 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".)

ekr____ 2mo ago
You're right. Bad writing on my part. Edited to make it clear.

throw0101d 2mo ago

> https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-8 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_vi57ceVcfmA75Hs/ https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...

chrismorgan 2mo ago
> there are already ML-KEM-only implementations in various libraries, so if we want interoperability then it's best to have a standard document “People are already doing it, so we might as well rubber-stamp it even if it’s not great” introduces problems of its own: people will perceive that rubber-stamping as validating it, and now they’ll use it even more, where perhaps if you held back, they wouldn’t. (There are counter-arguments as well, of course. A couple of relevant cases that spring to mind where a body has not aligned with usage or expectations: W3C lost control of HTML, and it was probably for the best, but they remain a relevant body in closely-related areas; and OSI licence approval is a horribly broken political process which is almost universally misunderstood and close to frozen in time, yet they haven’t suffered like they should have for their misdeeds, they pretty much got away with it. There was also that thing somewhat recently about FedRAMP rubber-stamping Microsoft Cloud despite it failing dismally, because US government agencies had already started using it too much; and I wonder what that does to their credibility.) This is also a concern with informational/independent submissions through IETF. They are frequently perceived as having IETF/standards weight.
- tptacek 2mo ago
  These are arguments, but I don't really understand what they're arguments for. At issue here is whether or not the IETF should document usage of pure-MLKEM TLS. There are environments where people are going to use pure-MLKEM TLS, whether Bernstein likes it or not. His argument is that the IETF should pretend that isn't happening, and throw up weird procedural obstacles to it.