[TLS] Re: draft-connolly-tls-mlkem-key-agreement
"D. J. Bernstein" <djb@cr.yp.to> Sat, 07 December 2024 02:19 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 EBFDFC14F682 for <tls@ietfa.amsl.com>; Fri, 6 Dec 2024 18:19:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Level:
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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] 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 DS5OrBlSDwIs for <tls@ietfa.amsl.com>; Fri, 6 Dec 2024 18:19:26 -0800 (PST)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by ietfa.amsl.com (Postfix) with SMTP id 1020FC14F680 for <tls@ietf.org>; Fri, 6 Dec 2024 18:19:25 -0800 (PST)
Received: (qmail 834 invoked by uid 1010); 7 Dec 2024 02:19:25 -0000
Received: from unknown (unknown) by unknown with QMTP; 7 Dec 2024 02:19:25 -0000
Received: (qmail 151873 invoked by uid 1000); 7 Dec 2024 02:19:11 -0000
Date: Sat, 07 Dec 2024 02:19:11 -0000
Message-ID: <20241207021911.151871.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org, jay@staff.ietf.org
Mail-Followup-To: tls@ietf.org, jay@staff.ietf.org
In-Reply-To: <CH0PR11MB5444B4B1006A10D99DBAB394C1312@CH0PR11MB5444.namprd11.prod.outlook.com>
Message-ID-Hash: AOW64Z4NWASNGY6SRYOVNBO57SQGXOLI
X-Message-ID-Hash: AOW64Z4NWASNGY6SRYOVNBO57SQGXOLI
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/qbX9hoq971Aq2yHUPVd-CrjJ_hA>
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>
I'm adding an RFC 9680 coauthor to the To line to request IETF LLC
attention to the antitrust issues here.
Scott Fluhrer (sfluhrer) writes:
> There are people whose cryptographic expertise I cannot doubt who say
> that pure ML-KEM is the right trade-off for them
Please note that antitrust law forces standardization organizations to
follow procedures that prevent anti-competitive activities. Here's an
introduction to the topic from the American Bar Association:
https://www.google.com/books/edition/Handbook_on_Antitrust_Aspects_of_Standar/zin5tgAACAAJ
Having a company influencing IETF decisions by making claims about what
customers are demanding---with no explanation of _why_ those demands are
being made, and no opportunity for IETF review of the merits of those
rationales---is exposing IETF to antitrust litigation. Even if the
specific incident at hand isn't meant to suppress competition, it shows
that IETF doesn't have the requisite procedural protections in place, so
it provides evidence helpful for _anyone_ who decides to sue IETF about
_any_ standardization topic.
As a side note, the "could still be construed as representing their
employer" part of RFC 9680 is certainly triggered by a message that's
adding weight to its argument by explicitly invoking the company's name
(in this case: "Cisco will implement it").
> I am essentially just asking for code points.
Hmmm. If the only request were for allocation from an open namespace
(which apparently has been done already), then why make claims about the
supposed desirability of omitting normal hybrid defenses? I also don't
see how the collective-action text ("I understand that people want to
discuss the hybrid KEM draft more (because there are more options there)
- can we at least get the less controversial part done?") can be
interpreted as merely an administrative allocation request. One followup
said "Can we start an adoption call?" and another said "+1".
Furthermore, email dated 24 Oct 2024 03:15:38 +0000, in the analogous
context of ML-DSA, said that "Cisco" has "some customers who want ML-DSA
only", and concluded that "we'll end up standardizing" that.
The ML-DSA discussion sounded like some people think that NSA refuses to
authorize U.S. government purchasing of hybrids (outside some special
circumstances). I asked whether that's true---whether NSA has in fact
banned hybrids. I quoted an official NSA statement saying "hybrid
solutions may be allowed or required due to protocol standards, product
availability, or interoperability requirements"; I said this "will be
triggered if, e.g., the TLS WG issues an RFC requiring all PQ in TLS to
be hybrid"; I haven't seen a counterargument.
Now the WG is again being told, again without a rationale, that some
unspecified cryptographic experts with money are demanding non-hybrids.
Even if it's true that NSA is banning hybrids (is it?), I'm opposed to
non-hybrids on security grounds and on BCP 188 grounds. But the more
basic point is that IETF's decisions on the topic have to comply with
IETF's procedural obligations under antitrust law.
---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