IETF Logo Mail Archive

[Last-Call] Re: [TLS] Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC

"D. J. Bernstein" <djb@cr.yp.to> Tue, 02 June 2026 23:13 UTC

Return-Path: <djb-dsn2-1406711340.7506@cr.yp.to>
X-Original-To: last-call@mail2.ietf.org
Delivered-To: last-call@mail2.ietf.org
Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 54434F9AF362 for <last-call@mail2.ietf.org>; Tue, 2 Jun 2026 16:13:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780442017; bh=aGHdLRjzWPaPmgSRLeprwPr/WCRt1KpYlbyHCILxBaI=; h=Date:From:To:Subject:In-Reply-To; b=jn1RS6W2S3Wi41rNmG3rM/iihqle4/HpwIHRDn7kw3KcBVPFdCP4UwFBdgDq9/kN1 acO65A9elN7AithpimcWpITBvROXtwQi+qmdXd+8zShA9M6NP4KZtunpgSzTFrQPNw NQ8eyru9HoVTqCtBH2/cy9DqUhsFKJ/8gAOqd6eE=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no
Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0uZ1kQS7QbCA for <last-call@mail2.ietf.org>; Tue, 2 Jun 2026 16:13:36 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id EA564F9AF35A for <last-call@ietf.org>; Tue, 2 Jun 2026 16:13:35 -0700 (PDT)
Received: (qmail 913009 invoked by uid 1010); 2 Jun 2026 23:13:35 -0000
Received: from unknown (unknown) by unknown with QMTP; 2 Jun 2026 23:13:35 -0000
Received: (qmail 2296304 invoked by uid 1000); 2 Jun 2026 23:13:32 -0000
Date: Tue, 02 Jun 2026 23:13:32 -0000
Message-ID: <20260602231332.2296302.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: Nadim Kobeissi <nadim@symbolic.software>, tls@ietf.org, last-call@ietf.org
Mail-Followup-To: tls@ietf.org, last-call@ietf.org
In-Reply-To: <20B1661B-4CF8-45D6-970E-31C63AFC8D44@symbolic.software>
Message-ID-Hash: 6H2QYX4IYQJABQUNJDQQT44AKRTKJC4D
X-Message-ID-Hash: 6H2QYX4IYQJABQUNJDQQT44AKRTKJC4D
X-MailFrom: djb-dsn2-1406711340.7506@cr.yp.to
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; 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: [Last-Call] Re: [TLS] Re: Last Call: <draft-ietf-tls-mldsa-03.txt> (Use of ML-DSA in TLS 1.3) to Informational RFC
List-Id: IETF Last Calls <last-call.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/last-call/qn790svUePW5lkxsSZWdMjg_wps>
List-Archive: <https://mailarchive.ietf.org/arch/browse/last-call>
List-Help: <mailto:last-call-request@ietf.org?subject=help>
List-Owner: <mailto:last-call-owner@ietf.org>
List-Post: <mailto:last-call@ietf.org>
List-Subscribe: <mailto:last-call-join@ietf.org>
List-Unsubscribe: <mailto:last-call-leave@ietf.org>

Nadim Kobeissi writes:
> The best way to address these potential issues in ML-KEM is through
> improved known-answer tests and other such testing methodologies:
> https://github.com/C2SP/wycheproof/pull/242

"Reactively patching [58] to address one bug at a time doesn't address
the systemic problem: the ecosystem is adding more and more lines of
ML-DSA code where bugs won't be caught by the tests actually being
applied to that code."

Source: <https://cr.yp.to/papers/mldsa-20260601.pdf#bugdenial>

For estimating the damage done by endorsing solo ML-DSA rather than
ECC+ML-DSA, one has to look at the bug rates produced by programming
practices in the actual software ecosystem. That's what my paper does,
carefully distinguishing this from various practices that I recommend.

Concrete example: You recently announced two bugs in Cryspen's ML-DSA
library (even calling them vulnerabilities). Presumably we can agree
that this library wasn't following best practices to avoid bugs. Do you
think all other ML-DSA libraries are following best practices?

If you agree that there will be continued bugs in ML-DSA software, the
dispute seems settled: sometimes bugs are severe vulnerabilities, so
having IETF endorse solo ML-DSA rather than ECC+ML-DSA is insane.

If you claim that there _won't_ be more bugs in ML-DSA software, I'd
like to understand why. This seems very far out of whack with extensive
evidence regarding bugs in a wide range of programming projects.

---D. J. Bernstein


===== NOTICES =====

IETF BCP 78, "Rights Contributors Provide to the IETF Trust", Section 5
(normative), "Rights in Contributions", provides a modification right
"unless explicitly disallowed in the notices contained in a Contribution
(in the form specified by the Legend Instructions)".

The official language from IETF's "Legend Instructions" for the
situation that "the Contributor does not wish to allow modifications nor
to allow publication as an RFC" is as follows: "This document may not be
modified, and derivative works of it may not be created, and it may not
be published except as an Internet-Draft."
<https://trustee.ietf.org/wp-content/uploads/Corrected-TLP-5.0-legal-provsions.pdf>

The same language is used in, e.g., RFC 5831. The same language hereby
applies to this document. This is not disclaiming or limiting the
applicability of IETF policies; it is strictly following IETF policies.

IESG claims that the "explicitly disallowed" provision in BCP 78 is
limited to the examples in Section 3 in BCP 78. That is incorrect. BCP
78 states that Section 5, "Rights in Contributions", is normative, while
Section 3, "Exposition of Why These Procedures Are the Way They Are", is
informative. The opt-out provision in the normative text is clear, and
cannot be limited by an informative section. BCP 78 does not give IESG
any authority to issue changes or purported clarifications of the rules.

Rationale for exercising the BCP 78 opt-out provision: I'm fine with
redistribution of copies of this document. The issue is instead with
modification, such as (1) IESG's May 2025 posting of an IESG-mangled
version of an appeal that I had filed and (2) IETF management selling
IETF mailing-list text to AI companies. This goes far beyond what
copyright law allows as fair use (such as giving quotes for purposes of
commentary). When I complained about the mangled document, the IETF
Executive Director responded not by apologizing but instead by asserting
that IETF management "has a license" to do anything it wants.

v2.46.0 | Report a Bug | By Email | System Status