NSA and IETF: Fairness

Original Article ↗ Hacker News Discussion ↗

A fight over how to standardize post‑quantum key exchange in TLS is exposing deep rifts in how much trust to place in both new lattice-based schemes (ML‑KEM/Kyber) and the Internet Engineering Task Force’s consensus process. Critics argue that publishing an RFC for “pure” ML‑KEM, without requiring hybrid use alongside established elliptic-curve methods and with only weak guidance on side‑channel resistance, risks creating a de facto endorsement of still‑immature cryptography, especially given the NSA’s and NIST’s history around weakened standards. Supporters counter that ML‑KEM was selected through an open competition, is already deployed and assigned TLS code points, and that documenting how to use it in TLS is necessary for interoperability rather than a mandate to adopt it.

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.