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

Filippo Valsorda <filippo@ml.filippo.io> Tue, 02 June 2026 17:36 UTC

Return-Path: <filippo@ml.filippo.io>
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 70BF0F96F319; Tue, 2 Jun 2026 10:36:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1780421808; bh=jgENi+iqoBiWChnEeUOrxoaeOYcidO0hzN7eijHlLU8=; h=Date:From:To:Cc:In-Reply-To:References:Subject; b=N1r88n/93U7rYhQH/J+Zwbs2cJMzEK8VKcP/pAHmAh6zTZU5+n2yeiSd7r2SHcIjv Wj5ew9yR8ERFGaT092ENrfEHIHo/xz/QEu6+0HeksM6HEnDfxQSwqPm2exyoATF7x1 kRO4V4VtbSuvn2P4A883x/mJ+NhueKNQKn3YreLY=
X-Virus-Scanned: amavisd-new at ietf.org
X-Spam-Flag: NO
X-Spam-Score: -2.697
X-Spam-Level:
X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=filippo.io header.b="D4SlnfzH"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="U1Wjwvvh"
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 qvYb8iTpoHkx; Tue, 2 Jun 2026 10:36:47 -0700 (PDT)
Received: from fout-b5-smtp.messagingengine.com (fout-b5-smtp.messagingengine.com [202.12.124.148]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id B55C0F96F1EE; Tue, 2 Jun 2026 10:36:07 -0700 (PDT)
Received: from phl-compute-09.internal (phl-compute-09.internal [10.202.2.49]) by mailfout.stl.internal (Postfix) with ESMTP id 437581D000C4; Tue, 2 Jun 2026 13:36:01 -0400 (EDT)
Received: from phl-imap-09 ([10.202.2.99]) by phl-compute-09.internal (MEProxy); Tue, 02 Jun 2026 13:36:01 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=filippo.io; h=cc :cc:content-type:content-type:date:date:from:from:in-reply-to :in-reply-to:message-id:mime-version:references:reply-to:subject :subject:to:to; s=fm3; t=1780421761; x=1780508161; bh=asNe81bi4/ vKC1BJPy3dKob+yH71aUY22WLvJSdKq8U=; b=D4SlnfzHa4yHB5wrN2TxUZKPke w4UdpREZUzg2CinfabNZha9ZIoxoPhlrnn9pKbAdUkNtIqnrfzOLeBujXKyOTcIF 6o5q58XfJNf0gERgAPTfDeVSf8KdF2ssX/awnNHzd8BDeMCeDHHbCr5bH7ITxJoX K0TpYyQqZQ/Q2e3HF/RRATpXVa+hX4qyScoh2CXn40x/14EQxd9zd2Yu782w69/O /Gvd9tNX1muNeHG0l/r0ETr5vDJKkiFA6Jtr48ynFWl74noybKg2WCcyG4acKf0x +qF+URrpk5Ta0jp+z5EDeAmMreSIujhMG5uOzBry6WVOZeXZSglkVBorIe8Q==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-type:content-type:date:date :feedback-id:feedback-id:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:subject:subject:to :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1780421761; x=1780508161; bh=asNe81bi4/vKC1BJPy3dKob+yH71aUY22WL vJSdKq8U=; b=U1Wjwvvhtgq5hUDluQzTjDIR7Vnn4gQBr8YV9xMWBpFeSpgbPz4 JyaTNzTFlXHsI2v0AiJmdHmQXPTsuNB5C7JiIHWBQazj/5KoH827vcYJ9BW6I94z YTLfDD7WJc7DXddcJC+3Sn/fjomEwoH6OrJMghNDvuXlTwZjnGKxbBkh1/PIO7nA Y6mIMxnVI9F7+TVzXjRj5/wO8JLpu2x8I869qdAwQDcvVL260OAqcSpwI/LTa81/ o9DzAmCBYuR8HjQmso6ST01ynvOf/2OpI5qTtJ1DPECehSQ5PS9wd/jpcjoq29J4 Oiy07uR0qN+fN2hZOESYSDaSnlcBdVZPObA==
X-ME-Sender: <xms:gBQfavBLu-ybgQxZYOaw39bkGDYPdZUP7HD4rRMQt1Ly0cj9pNhOfA> <xme:gBQfagXJxw5mRBuOpwWZN2P_u49tcoKBwhYijXOxnvJY51fNEt0cTMMFnya8HJ1Zl y-I1A9jyygDK0DNQcJG8qyyNy4zIjm6m5AqflRFxGxFJrJgdAdf>
X-ME-Proxy-Cause: dmFkZTGmV0UnLfRIBnTEaXwJCilVbTAFiT//uqFfJazzMwIwiZzlDaU73ajDkQ/9dkaoLG 1QHpnnQIqt4+inidK4F1JPS2ziPOodhtfjKuzQL1PvDZvcOWPLtqUA47foAW2XAW4zpceT 5ZWTztXWS/SEV2kL2MmX4XjF1P5CDWk0DCKrJB3x7kFcRdTV9MtWCOErJMnhTAhc8JeL1e 0RoT94IM4AC0DcwNpdHxEc84AnPFjiy5ifGvIbDeEDEFF0EYW9ViKXE52ltg2ptqyr2CIj PrD50GtP/OvumHWnvsZ3M5+59JwiG2xn5sla547oVam03N/cICCUS96SyX8sfuDk0KeUe/ 4rtAoukPCho9VFkIn00Rz3mqUdzOqWN5YFhxhwizjf7FKzlflORt2j2K7bIAsAYEFiBL7N tsbxaiLbXUGrP+4QXKfEb/Iw+gVyJplY/OC+RbcBsoVN667+jD/uGorQC10TIQrmWnxUDc w80emSX6rnWsRzbrvtdUSohn0WCb2kqqHxQM4O+JWtKcD9igW/Uq7b0fJP7EDrfglIyH5k xzpKK3aV5jhuXnEz45c+Xtx8AyPPYcOFK3ADbzDlnJrYjbgE6HItt0otFc2XTmPNNlHtT6 vH6R1BzxUxcN2IwV3fo1GlaIlyuDqGg69aF8OVc+Esx5tttKYpcgZlKXh3zQ
X-ME-Proxy: <xmx:gBQfavgXtEvDRe5e6-7ThW-fuljByzq0KjZ7TV2RekSpP3p96gJn8w> <xmx:gBQfajf8qOPBdnZcHlMySVNgWh7XOxbiOdkVF0BcT5FaBrlEd5iTrA> <xmx:gBQfasfVviopnfEgj43ooDhVDCVVpzFoBuFTUhnK9_QDtfbYl9alQQ> <xmx:gBQfal9TkDVzQy-9kKPwDusswxGyJpsXtMEn2Y8o1SfpYRnAP0I1FA> <xmx:gRQfanmRdk6kPzMmSZSe6YisVyfsQnPtpGESXE6jWS_BT-xqRcW-Dry3>
Feedback-ID: i2e91459c:Fastmail
Received: by mailuser.phl.internal (Postfix, from userid 501) id A4A5A302009B; Tue, 2 Jun 2026 13:36:00 -0400 (EDT)
X-Mailer: MessagingEngine.com Webmail Interface
MIME-Version: 1.0
X-ThreadId: AfKUvwr66x4F
Date: Tue, 02 Jun 2026 19:34:39 +0200
From: Filippo Valsorda <filippo@ml.filippo.io>
To: Russ Housley <housley@vigilsec.com>
Message-Id: <85821685-f12a-41e2-a136-3b068647b7f7@app.fastmail.com>
In-Reply-To: <767067D3-A1FF-452D-B1BE-76B412E75052@vigilsec.com>
References: <20260601204245.2216938.qmail@cr.yp.to> <767067D3-A1FF-452D-B1BE-76B412E75052@vigilsec.com>
Content-Type: multipart/alternative; boundary="696608af083f21fa4f7920277fddffe863f723f2"
Message-ID-Hash: ZROJCEE2FO4MXDBNCV5SLQC5347RTJ45
X-Message-ID-Hash: ZROJCEE2FO4MXDBNCV5SLQC5347RTJ45
X-MailFrom: filippo@ml.filippo.io
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
CC: IETF TLS <tls@ietf.org>, last-call@ietf.org
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/psBYiEzd6MeIbN8RhBUCHpb25a0>
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>

2026-06-02 16:23 GMT+02:00 Russ Housley <housley@vigilsec.com>:
> 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.

There is no need anyway.

Bernstein looks for severe bugs in ML-DSA implementations, and only finds one in a *2017* implementation of Dilithium 1.0, and then *invents* three bugs that resemble it. All four would be found by running *any* KATs for *any signing interface*, including the high-level non-internal deterministic signing one.

This paper could have been a few uninteresting entries in a muzoo <https://github.com/FiloSottile/mostly-harmless/tree/main/muzoo> mutations folder.

Some of the surrounding 50 pages of stuff make claims that are at best confused and at worst intentionally obtuse. For example on page 15 he claims he can't see how to use a test vector that provides (seed, public key, message, µ, signature) <https://github.com/C2SP/wycheproof/blob/878e5366008753df2064d40c49f8e2f50f9c6af7/testvectors_v1/mldsa_44_sign_seed_test.json> to test a signing interface that does (seed, message) => (signature) or a key generation interface that does (seed) => (public key). These misunderstanding seem to mislead other parts of the paper such as claiming a trivially-caught bug "can’t be caught by the nonexistent ML-DSA keygen tests in [Project Wycheproof]" or that "[Project Wycheproof] seems to require a nonstandard interface to test ML-DSA signature generation, and it doesn’t test ML-DSA key generation at all."

These bugs are so easy to find that they would be caught by the vectors in the body of draft-celi-acvp-ml-dsa <https://pages.nist.gov/ACVP/draft-celi-acvp-ml-dsa.html>, without even accessing actual ACVP vectors provided by NIST at https://github.com/usnistgov/ACVP-Server/tree/master/gen-val/json-files, which Bernstein somehow wrote a 59-page paper about testing ML-DSA without referencing.

> Russ
> 
> > On Jun 1, 2026, at 4:42 PM, D. J. Bernstein <djb@cr.yp.to> wrote:
> > 
> > I've just finished a paper titled "Exploiting ML-DSA bugs":
> > 
> >    https://cr.yp.to/papers.html#mldsa
> > 
> > Let me gently suggest that IESG extend the current "last call" and ask
> > the TLS WG chairs to stop censoring my messages to the TLS mailing list.
> > 
> > The abstract of the paper is as follows:
> > 
> >    At least four Dilithium software vulnerabilities have been announced
> >    so far, including an identical vulnerability in each of the two
> >    official Dilithium 1.0 implementations and two different
> >    vulnerabilities in a "verified" implementation of Dilithium 3.4,
> >    also known as ML-DSA. However, there do not appear to have been any
> >    demos showing exploitability of any of these vulnerabilities.
> > 
> >    This paper shows that a small change in ML-DSA software creates an
> >    ML-DSA version of the Dilithium 1.0 software vulnerability, can
> >    occur by accident as in the original vulnerability, interoperates
> >    with authentic ML-DSA, passes typical tests, and is exploitable in 1
> >    second on 1 laptop core. This paper provides an open-source attack
> >    demo that inspects a public key and two signatures, obtains an
> >    equivalent secret key, and uses this key to rapidly forge signatures
> >    on attacker-chosen messages.
> > 
> >    This paper also shows that another small change in ML-DSA software
> >    creates a different software vulnerability, can occur by accident as
> >    in the Sony PlayStation 3 ECDSA vulnerability, interoperates with
> >    authentic ML-DSA, passes typical tests, and is exploitable in 1
> >    second on 1 laptop core. This paper again provides an open-source
> >    attack demo that rapidly forges signatures on attacker-chosen
> >    messages, after inspecting a public key and a few signatures.
> > 
> >    This paper then uses standard techniques to estimate exploitability
> >    rates for ML-DSA software, and to estimate the number of ML-DSA keys
> >    that the attacker will be able to break in year Y, as a function of Y.
> > 
> >    This paper also reviews evidence in the literature regarding quantum
> >    timelines, costs of quantum attacks, and non-quantum security
> >    failures in ECC, so as to estimate the number of Ed25519+ML-DSA
> >    double-signing keys that the attacker will be able to break in year
> >    Y. The main conclusion is that, even years after the first quantum
> >    attack, this number will still be much smaller than the number of
> >    breakable ML-DSA keys.
> > 
> >    Qualitative security benefits of ECC+PQ compared to solo PQ have
> >    been pointed out before, but not with quantified estimates of the
> >    number of breakable keys. Some recent postings gave arguments
> >    disputing these benefits; this paper closes by pointing out flaws in
> >    those arguments.
> > 
> > ---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 is clear, and cannot
> > be limited by an informative section. BCP 78 also 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.
> > 
> > -- 
> > last-call mailing list -- last-call@ietf.org
> > To unsubscribe send an email to last-call-leave@ietf.org
> 
> _______________________________________________
> TLS mailing list -- tls@ietf.org
> To unsubscribe send an email to tls-leave@ietf.org
>

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