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 _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
