[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
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Watson Ladd
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Jay Daley
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Russ Housley
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Andrey Jivsov
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Deirdre Connolly
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Scott Fluhrer (sfluhrer)
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Salz, Rich
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement John Mattsson
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Alicja Kario
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Andrei Popov
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Sean Turner
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Filippo Valsorda
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Rob Sayre
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Santosh Chokhani
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Jay Daley
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Sophie Schmieg
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Jay Daley
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Dan Harkins
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Jay Daley
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Sophie Schmieg
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Deirdre Connolly
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Joseph Salowey
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Deirdre Connolly
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Viktor Dukhovni
- [TLS] draft-connolly-tls-mlkem-key-agreement Scott Fluhrer (sfluhrer)
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement John Mattsson
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Scott Fluhrer (sfluhrer)
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Salz, Rich
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Filippo Valsorda
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement John Mattsson
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Stephen Farrell
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Viktor Dukhovni
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Loganaden Velvindron
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Stephen Farrell
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… John Mattsson
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement John Mattsson
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Joseph Birr-Pixton
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement John Mattsson
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… John Mattsson
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Alicja Kario
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Bas Westerbaan
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… Watson Ladd
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… D. J. Bernstein
- [TLS] Re: draft-connolly-tls-mlkem-key-agreement Blumenthal, Uri - 0553 - MITLL
- [TLS] Re: [EXT] Re: draft-connolly-tls-mlkem-key-… D. J. Bernstein