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

"D. J. Bernstein" <djb@cr.yp.to> Thu, 12 December 2024 17:28 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: tls@ietfa.amsl.com
Delivered-To: tls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C49C8C1516E9 for <tls@ietfa.amsl.com>; Thu, 12 Dec 2024 09:28:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, PP_MIME_FAKE_ASCII_TEXT=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, UNPARSEABLE_RELAY=0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J3xNVktXwE0b for <tls@ietfa.amsl.com>; Thu, 12 Dec 2024 09:28:55 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 02AD8C14F714 for <tls@ietf.org>; Thu, 12 Dec 2024 09:28:54 -0800 (PST)
Received: (qmail 8409 invoked by uid 1010); 12 Dec 2024 17:28:53 -0000
Received: from unknown (unknown) by unknown with QMTP; 12 Dec 2024 17:28:53 -0000
Received: (qmail 553103 invoked by uid 1000); 12 Dec 2024 17:28:40 -0000
Date: Thu, 12 Dec 2024 17:28:40 -0000
Message-ID: <20241212172840.553101.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org, jay@staff.ietf.org, legal@ietf.org
Mail-Followup-To: tls@ietf.org, jay@staff.ietf.org, legal@ietf.org
In-Reply-To: <810BAD96-934C-4B1F-9DD4-96433A855A12@staff.ietf.org>
Message-ID-Hash: QRVBWGOWUHYPMNF6XUEPZCB7MQBU7GRW
X-Message-ID-Hash: QRVBWGOWUHYPMNF6XUEPZCB7MQBU7GRW
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-tls.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
X-Mailman-Version: 3.3.9rc6
Precedence: list
Subject: [TLS] Re: draft-connolly-tls-mlkem-key-agreement
List-Id: "This is the mailing list for the Transport Layer Security working group of the IETF." <tls.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/tls/aNUrCz01kmhm-cXGdp6FaLbA3K4>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tls>
List-Help: <mailto:tls-request@ietf.org?subject=help>
List-Owner: <mailto:tls-owner@ietf.org>
List-Post: <mailto:tls@ietf.org>
List-Subscribe: <mailto:tls-join@ietf.org>
List-Unsubscribe: <mailto:tls-leave@ietf.org>

RFC 9680 coauthor writes:
> If, on the other hand, your concern is that there has been a failure
> of IETF processes that has created an antitrust risk, then the
> appropriate course of action is to follow the appropriate IETF process
> for addressing that.

RFC 9680 says that it's "generally inappropriate" to discuss "market
opportunities for specific companies". What's the IETF process for
addressing violations of RFC 9680?

As part of messages to tls@ietf.org advocating IETF action, a Cisco
employee claimed market opportunities for Cisco: "There are people whose
cryptographic expertise I cannot doubt who say that pure ML-KEM is the
right trade-off for them, and more importantly for my employer, that’s
what they're willing to buy." The message was from a Cisco address and
also went out of its way to specifically name Cisco in the text.

I find it perfectly clear how antitrust litigation can address this. I
don't find it clear that there are effective IETF procedures to address
this. I sent email requesting IETF LLC attention to this Cisco incident;
the response didn't acknowledge the incident and didn't suggest specific
followup procedures beyond this vague "appropriate IETF process" note.
Hence my question above.

> If your concern is that the IETF processes contain an overlooked
> antitrust risk

That's certainly an issue too. One of my messages quoted, e.g.,

    https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:52011XC0114(04)

asking whether there are "objective criteria for selecting the
technology to be included in the standard". My message continued by
asking where IETF's objective criteria are for deciding what to select,
and where the documentation is that demonstrates systematic enforcement
of those criteria.

RFC 9680 quotes BCP 9 text claiming that BCP 9 is designed to "provide a
fair, open, and objective basis for developing, evaluating, and adopting
Internet Standards". However, BCP 9 later contradicts this: first it
waters the claim down to just "reasonably" objective, and then it admits
that "there is no algorithmic guarantee". Furthermore, anyone trying to
find a statement of criteria in BCP 9 finds

    * broad non-objective criteria (e.g., "considered to be useful"),
    * no explanation of how different criteria are weighted, and
    * open-ended flexibility for the decision-makers (e.g., "IESG may").

The specific situation at hand illustrates the problem. How does anyone
figure out whether Cisco's claim of market opportunities is relevant to
the BCP 9 criteria? This isn't an isolated incident---we've seen such
claims being raised again and again as arguments to override BCP 188
concerns, other security concerns, and other technical concerns.

---D. J. Bernstein