NSA and IETF: Fairness

Original Article ↗ Hacker News Discussion ↗

Scope of the dispute

  • Thread focuses on whether the IETF TLS working group should publish an informational RFC describing pure-ML-KEM use in TLS (post‑quantum KEM without ECC hybrid), and on the fairness of the process.
  • The article’s author is a central critic of the process and of ML-KEM, but discussion ranges more broadly over standards governance, NSA influence, and PQC maturity.

IETF process: “rough consensus” vs “voting”

  • Some argue calling WG decisions “votes” is misleading and weakens procedural objections; IETF explicitly works by “rough consensus,” not counting heads.
  • Others note that, in practice, chairs and processes can still be gamed, but see legal arguments about “consensus” and antitrust carve‑outs as overblown or legally naive.
  • There’s concern that harsh criticism of IETF alienates people who still see it as largely doing good work, despite some bad actors.

Status of ML-KEM in TLS

  • ML-KEM-only named groups already have IANA codepoints; the draft mainly specifies how to use them in TLS and is marked “recommended = N.”
  • Hybrid ECC+ML-KEM is already standardized and recommended; the dispute is about documenting pure ML-KEM as an option.
  • Some say there’s no procedural need to push this through IETF at all: any public specification suffices for codepoints, and an independent RFC stream is (theoretically) possible.

Security, maturity, and side-channel concerns

  • One side: lattice KEMs like ML-KEM are about as well‑studied (for their age) as ECC was when it became mainstream; ML-KEM has formal analyses, deployment history, and hybrid TLS is already widely used.
  • Other side: PQC (and ML-KEM specifically) is newer, with notable implementation flaws (e.g., KyberSlash timing leaks); technology for robust side-channel‑safe implementations is still immature.
  • Strong criticism that FIPS 203 and the ML-KEM TLS draft treat side‑channel resistance as optional “encouragement” rather than normative requirements; contrasted with more specific guidance in some past RFCs.
  • Some argue standards should be explicitly misuse‑resistant and avoid “footguns” like powerful but side‑channel‑fragile options.

Hybrid vs pure ML-KEM

  • Pro‑hybrid view: since PQC maturity and side-channel behavior are uncertain, PQ should be added to existing ECC, not replace it; several European governmental guidelines explicitly recommend hybrid in the short–medium term.
  • Skeptical-of-hybrid view: for well‑designed schemes, ECC+ML-KEM gives marginal real benefit (like cascading strong ciphers) while adding complexity; a formal proof exists that a certain hybrid remains secure even if ML-KEM fails.
  • Some note environments (e.g., telecoms) that reportedly “have to” use pure ML-KEM, so documenting it aids interoperability rather than forcing use.

Role of NSA and trust in standards

  • One camp emphasizes NSA’s historical role: pushing weaker key sizes in DES, the Dual_EC_DRBG backdoor episode, 1990s export restrictions, and current classified Suite A algorithms as reasons for deep suspicion.
  • Others counter that:
    • ML-KEM was designed by academic teams, not an intelligence agency.
    • The main national standards body and a signals-intelligence agency are distinct, with sometimes conflicting incentives (offense vs defense).
    • NSA’s own move to use ML-KEM at high classification levels suggests confidence rather than a deliberate backdoor.
  • A minority argues that the pattern of intelligence-agency pressure against hybrids is itself suspicious and justifies extreme caution.

Impact of publishing (or not) the RFC

  • Some say publishing an informational RFC with “not recommended” status simply reflects existing practice and supports other SDOs (e.g., telecom and wireless bodies) that have sent liaisons asking for a stable reference.
  • Others argue that any RFC, even informational, confers “RFC sheen” and will increase deployment, including in contexts where pure ML-KEM may be an unnecessary or unsafe risk.
  • There’s disagreement over whether “people already doing it” is a valid reason to standardize, or a path to rubber‑stamping questionable practices.

Process manipulation and brigading

  • Several comments allege coordinated “brigading” of the TLS mailing list by critics of ML-KEM-only TLS, including template subject lines and calls to join just to oppose the draft.
  • IETF participants reiterate that apparent “vote counts” are not decisive; strong technical arguments and implementer consensus can outweigh raw numbers.
  • If the WG declines to publish, the ML-KEM codepoints remain valid; the main difference is the loss of an official TLS-binding RFC.