[TLS] Re: draft-connolly-tls-mlkem-key-agreement

["D. J. Bernstein" <[e-mail]>]

Watson Ladd writes:
> Having MLKEM without a hybrid as an option in TLS when the interoperable
> choice is a hybrid

Some previous messages claim that there's a split between customers
demanding hybrids and customers demanding non-hybrids so "we'll end up
standardizing both". If the claim is true (I'm skeptical about the
non-hybrid part) and IETF acts on it (which is what I'm objecting to),
then how exactly does a hybrid end up as "the interoperable choice"?

Procedurally, IETF should bar this claim on antitrust grounds, and make
the decision on technology grounds. Security is job #1 (see BCP 188, for
example, and the name of the WG); non-hybrids are a security threat (see
SIKE, for example, or KyberSlash); counterarguments such as cost don't
hold up to examination (see https://blog.cr.yp.to/20240102-hybrid.html)
a technology-based decision will end up prohibiting non-hybrids. This
does make it possible to aim for a hybrid as "the interoperable choice",
but also means that, given the security risks, non-hybrids won't be
allowed even as an option. As an analogy, see RFC 7465.

> is not going to exclude people.

There's an internal NSA history book that's perfectly clear about NSA's
anti-competitive goals for low-security standards: "Narrowing the
encryption problem to a single, influential algorithm might drive out
competitors, and that would reduce the field that NSA had to be
concerned about."

NSA isn't bound by antitrust law, but IETF is. The law doesn't wait for
anti-competitive effects to be demonstrated: it proactively imposes
various pro-competitive procedural constraints, including specific
constraints on standards-development organizations, such as transparency
requirements that obviously aren't being followed here.

> Furthermore we didn't hybridize x25519 and RSA.

Did IETF receive any RSA+X25519 drafts? Citation needed.

> It's clear some people believe ML-KEM is secure enough for their uses.

Back in 2013 and 2014, there were claims on this mailing list and on the
UTA mailing list about RC4 (1) not being so bad for security (e.g., "For
TLS 1.0, a case can be made that RC4 is the best choice, or the
least-worst") and (2) being important to keep for compatibility with the
WG's previous standards. The WG went ahead and banned RC4 anyway.

> There also is no protocol police: code points for this will exist
> regardless of what the IETF does with the draft.

I've quoted specific proposals for WG adoption of non-hybrid drafts. If
those proposals are being withdrawn, great.

---D. J. Bernstein