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 16:53 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 D473DF964D63 for <last-call@mail2.ietf.org>; Tue, 2 Jun 2026 09:53:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780419239; bh=CENbZJHVd4tBS/u2cYLPBWxfSjdnuVN8J/yyU6KlWqY=; h=Date:From:To:Subject:In-Reply-To; b=CbEoEGvRi2zx4qHHEeyEZkP9Db8SWHE874APWvwmPprAZZsQMLM/WnbL9DWgxOCHZ X/HVSNwrl9WUvQxKxtHcqN2D1oQ939LWs5DAUUtwncpd2pygqMCkWz3Pa9qrR6fpdu 2veRezTFgew5rLTHmWuutkQJ4ZBwqx08UQ2U0eZI=
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 Rwtz_ONVVzBg for <last-call@mail2.ietf.org>; Tue, 2 Jun 2026 09:53:53 -0700 (PDT)
Received: from salsa.cs.uic.edu (salsa.cs.uic.edu [131.193.32.108]) by mail2.ietf.org (Postfix) with SMTP id 0DDF4F96388F for <last-call@ietf.org>; Tue, 2 Jun 2026 09:47:07 -0700 (PDT)
Received: (qmail 901725 invoked by uid 1010); 2 Jun 2026 16:47:06 -0000
Received: from unknown (unknown) by unknown with QMTP; 2 Jun 2026 16:47:06 -0000
Received: (qmail 2276560 invoked by uid 1000); 2 Jun 2026 16:47:05 -0000
Date: Tue, 02 Jun 2026 16:47:05 -0000
Message-ID: <20260602164705.2276558.qmail@cr.yp.to>
From: "D. J. Bernstein" <djb@cr.yp.to>
To: tls@ietf.org, last-call@ietf.org
Mail-Followup-To: tls@ietf.org, last-call@ietf.org
In-Reply-To: <767067D3-A1FF-452D-B1BE-76B412E75052@vigilsec.com>
Message-ID-Hash: RAWQ7QEU27KAMXWPMQCZFPVNNGGQ4VLR
X-Message-ID-Hash: RAWQ7QEU27KAMXWPMQCZFPVNNGGQ4VLR
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/TwPWFLJ7aYgP8gL4ShSrUGGpOTU>
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>

Russ Housley writes:
> With the notice that you attached to this note, it cannot be used to
> improve the Security Considerations of draft-ietf-tls-mldsa-03.  As
> such, this is very unhelpful.

Maybe I wasn't clear enough. I'm not contributing text to this spec. I'm
saying that this spec is an unmitigated security disaster and has to be
thrown away.

Concretely, as https://cr.yp.to/papers.html#mldsa explains in detail,
deploying solo ML-DSA will result in many keys being breakable because
of the predictable pile of severe vulnerabilities in ML-DSA software
(never mind other ML-DSA risks), whereas the common-sense mitigation of
deploying ECC+ML-DSA will result in far fewer keys being breakable. This
will remain true even years after the first quantum attacks.

Solo ML-DSA is an incorrect technical choice that places the quality and
integrity of the TLS WG's output---and IESG's output---in a situation of
not just significant jeopardy but clear security damage, some of which
will inevitably become visible in CVEs. IESG and the WG will share
culpability for this security damage. Labeling an RFC as informational,
not recommended, etc. does not stop most readers and purchasing managers
from viewing the RFC as IETF endorsement.

Is that sufficiently clear?

---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. There's no legitimate excuse for
that, and it goes far beyond what copyright law allows as fair use, such
as giving quotes for purposes of commentary.

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