Disappointed that there is not more discussion about this as this looks to be a slow march to the government getting its way with a technology that will affect so many.

Highly recommended reading for effectively understanding the behavior patterns of bad-faith participants in such exchanges: https://www.scribd.com/document/345154863/Guide-to-Forum-Spi...

If the link goes down, the content is available in many other places across the web under the title "The Gentleman's Guide To Forum Spies (spooks, feds, etc.)"

DJB keeps calling the IETF consensus process "voting". That's detrimental to his own case; when there is a vote, the vote can be manipulated. It makes much more sense to argue there is no consensus, which should be quite obvious at this point, and which can be argued even in a "60:40" situation regardless of direction. It also avoids alienating "true IETF believers".

Apart from that, the crux of this is the codepoint allocation in the named group registry. [https://www.iana.org/assignments/tls-parameters/tls-paramete...] The requirement for that allocation (with "recommended=N" - which is what this draft has) is "Specification Required", not "IETF consensus". "Specification" for IANA registries doesn't mean IETF documents, it means:

  […] must be documented in a permanent and readily
  available public specification, in sufficient detail so that
  interoperability between independent implementations is possible.

[https://datatracker.ietf.org/doc/html/rfc8126#section-4.6]

As such I don't understand why the authors are so intent at ramming this through the IETF process when they could just put the same document whereever. The process has been sufficiently and publicly fraught enough to destroy any "reputation" that might (or might not) come associated with it being published as IETF RFC.

[ed.: referenced wrong registry, it's named groups, not cipher suites. Makes no difference, same registration procedure.]

FTR, the only [preliminary] entry with recommended=Y for PQ crypto is:

  4588  X25519MLKEM768  Combining X25519 ECDH with ML-KEM-768  https://datatracker.ietf.org/doc/html/draft-ietf-tls-ecdhe-mlkem-05

This post was pretty technical. Let's explain a couple of terms:

ML-KEM -- Module-Lattice-Based Key-Encapsulation Mechanism

ML-DSA -- Module-Lattice-Based Digital Signature Algorithm

solo PQ -- Using post-quantum crypto on its own

ECC+PQ -- Using post-quantum crypto as a layer on top of traditional elliptical curve cryptography (ECC)

So what's at stake here, is that the PQ crypto is not proven yet, and had recent implementation vulnerabilities (Kyberslash 1 & 2).

In the NSA's defense, combining cryptosystems also creates attack surfaces, timing problems, additional complexity, etc. Perhaps they know something we don't. They have sometimes acted to strengthen public cryptography, as with the DES S-boxes and differential cryptanalysis. Of course, they also weakened the key-space...

> Secret NSA documents showed that NSA pushed DES in the 1970s to "drive out competitors" while knowing that DES was "weak enough" to break; meanwhile NSA publicly claimed that it would use DES

Is this true? The NSA pushed for weaker cryptography it could break versus stronger cryptography our adversaries couldn't?

The two most important things to understand about this kerfuffle:

(1) MLKEM wasn't designed by NSA, but rather by a team of highly-regarded European academic cryptographers, including Bernstein's former collaborator Peter Schwabe; their submission, Kyber, was selected in an open competition in which Bernstein himself submitted a closely-related algorithm (and then contested the result, suing NIST for documents to clarify the selection.)

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

Every time Bernstein talks about NSA's sordid history, remember: nothing that's happening here has really anything to do with NSA. It would make more sense for Bernstein to be canvassing against SHA2, which NSA actually did design. But he can't do that, because normal people know enough about cryptography to understand how crazy a claim that is. Unfortunately, we can't yet say that about lattice cryptography, despite it being approximately as well-studied as ECC.