NSA and IETF: Fairness

DJB has orchestrated a vote rigging campaign against this WGLC, encouraging users to join the list and vote/express their opinion and providing the exact subject header to use. Have any other sides been saying, essentially, just join the group and say you’re for/against?

He’s been moderated during the last call because of his email disclaimer/footnote, and apparently refuses to respond on list during this time. Seems like he’s playing a few steps ahead where he can (yet again) cry foul on the system and cry foul on vote rigging. Despite him being a key instigator. I’ve already seen at least one poster reference a RFC explaining how IETF consensus works and how its not a pure numbers game (5 for and 100 against can still be consensus, depending on the circumstances; the inverse also applies).

What’s his next step if the authors publish as an information RFC? He can’t stop that, right?

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.

> 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?

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

Is there anything different about this DJB mailing list brigading than the other brigading he's done?

Four days ago: https://news.ycombinator.com/item?id=48760490

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" (ed.: I am one).

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.

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

if i were the nsa, I'd have spent all my research money on attacking ecc+pq, because 1. no self respecting security engineer would deploy bare pq (see cloudflare), 2. no phd research team would attack the combination (well, not before until it's too late) because that's harder than a phd requires (they will target solo pq or solo ecc). 3. it's much easier to "sell". q.e.d. this article.

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

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.