Discussion summary
The NSA and GCHQ are reportedly attempting to influence cryptographic standards to weaken ECC+PQ hybrid algorithms, raising concerns about security and trust in standards organizations.
What the discussion says
- Some believe the NSA's efforts aim to weaken cryptographic standards, potentially enabling downgrade attacks.
- Others argue that the support for hybrid KEMs is already established and the concerns may be overstated.
- Critics highlight distrust in NSA and NIST, citing past sabotage and advocating for independent standards.
“Surveillance agencies are trying to have standards endorse weakening ECC+PQ.”
“Hybrid KEMs are already supported and recommended in RFCs.”
Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Perhaps worth noting Section 6, "Security Considerations", of the most recent draft has:
> Recommended: N
* https://datatracker.ietf.org/doc/html/draft-ietf-tls-mlkem-0...
Pure, non-hybrid implementations of ML-KEM (FIPS 203, previously "Kyber") are already in the major crypto libraries. So given code is being written, there can either be an IETF document available to ensure interoperability or not: the IETF would prefer interop it seems.
The list of IETF-recommended TLS algorithms can be found under the (sortable) "Recommended" column of officially registered TLS parameters:
* https://www.iana.org/assignments/tls-parameters/tls-paramete...
The list is currently: X25519MLKEM768, x448, x25519, secp384r1, secp256r1. The document being discussed/debated would not change it.
by throw0101d - What exactly is the problem with the IETF publishing a standard that's theoretically weaker than another standard? They're not forcing anyone to use it, right?by Ajedi32
- Clicking around I don't see any "nsa.gov" email addresses for the positions this site says are from the NSA. Have I just missed some things that are clearly from the NSA? If not, how would one know that these various academic and personal email addresses have some kind of NSA tie?by advisedwang
- If you're reading this thread wondering why the IETF wants an informational (non-standards track), Recommended=N RFC that specifies how to use ML-KEM without ECDH, there's some important background reading.
https://mailarchive.ietf.org/arch/msg/tls/SXo4iVmp0ng_vi57ce...
https://keymaterial.net/2025/11/27/ml-kem-mythbusting/
Additionally, I wrote my own blog posts recently that toucbed on the subject.
Signatures: https://soatok.blog/2026/04/13/hybrid-constructions-the-post...
Threat modeling but also KEMs: https://soatok.blog/2026/06/30/soatoks-informal-guide-to-thr...
The main industry that's hamstrung by an RFC being blocked are telecom companies (e.g., Verizon) who by policy need an RFC and also have other regulations.
I prefer hybrid KEMs, but support publication because getting those companies onto PQ is harm reduction against Harvest Now, Decrypt Later (HNDL) attacks, and ECDH doesn't help if our confidence in the security of ML-KEM turned out to be wrong.
by some_furry - This is garbage from start to finish.
There are already codepoints assigned for MLKEM 512/768/1024 (0x0200, 0x0201, 0x0202) and nearly every major library supports it already:
- OpenSSL (ML-KEM-512/768/1024) - BoringSSL (ML-KEM-1024) - NSS (ML-KEM-1024) - AWS-LC (ML-KEM-512/768/1024) - Rustls (ML-KEM-768/1024) - s2n-tls (ML-KEM-1024) - Bouncy Castle (ML-KEM-512/768/1024) - Botan (ML-KEM-512/768/1024) - GnuTLS (ML-KEM-768/1024) - WolfSSL (ML-KEM-512/768/1024)by galadran - The NSA is not trying to weaken ML-KEM. The IETF TLS working group is simply trying to publish a pure ML-KEM specification. It does not impact the hybrid ietf-tls-ecdhe-mlkem specification at all.
The context of this is that D.J Bernstein has been moderated 7 times from the mailing list for repeated unprofessional and disruptive behavior: https://mailarchive.ietf.org/arch/msg/tls/lON9lKptnJ6ccq2-I1...
by sweis - This has been discussed before, and I believe the general consensus is that djb's objections don't make sense. The Key Material blog addresses this in a very good larger ML-KEM mythbusting post: https://keymaterial.net/2025/11/27/ml-kem-mythbusting/#:~:te...by miloignis
- This is not an unbiased article about the situation unfolding on the TLS Working Group mailing list; this is a call to action to join one specific side of the argument that has been ongoing for over a year now. It's an appeal to authority, an attempt to garner support for one side of the debate simply because DJB says so, as part of his effort to flood the zone with messages in opposition.
This tactic is explicitly called out in RFC 7282, and named as a "degenerate", "pathological", and "dysfunctional" state for the working group to be in. Shame on DJB for attempting to drive the working group into terminal dysfunction.