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

[Nadim Kobeissi <[e-mail]>]

Hi Dan,

(Writing this quickly so that I can still make it to the grocery store to buy cranberries before they close),

> No, I'm not. See, e.g.,
> 
>    https://web.archive.org/web/20260603074058/https://mailarchive.ietf.org/arch/msg/spasm/pcISUlnedpExwwLuISP18oR1zxc/

Reply to this link plus the large explanation following it: that’s great. I can see you certainly put a lot of effort in that thread to make a good deal of consistent points. Thanks for pointing it out to me.

> This quote (which is not from me)

I didn’t mean to imply that I was quoting you directly. The informal writing style I hoped indicated that I was just trying to roughly summarize your stance.

> downplays (1) the instability of
> lattice security levels and (2) the further risks that come from the
> ML-DSA attack surface _beyond_ general lattice attacks. My new paper
> cites some examples of broken lattice systems and recent attack
> advances: see https://cr.yp.to/papers/mldsa-20260601.pdf#mathdenial.


Look, those things were discussion points during the standardization phase. Now, ML-DSA is the standard. We have standardization processes for a reason. If you think its security levels are overblown, apply for a grant and show that that’s the case. Work with other lattice cryptography experts to find breaks! This will be more convincing than petitioning a TLS mailing list, and would lead to groundbreaking new scientific results to boot!

> we will see severe vulnerabilities in ML-DSA
> software---which will produce many more breakable ML-DSA keys than
> breakable ECC+ML-DSA keys.

I think everyone agrees that we will see severe vulnerabilities in *all* software. This is a risk we mitigate against through best-practice software engineering, through better research and through test vectors. We accept that risk and mitigate against it every day, and here, I think people have decided that this daily work on mitigation and continuous study makes it such that hybrids for signatures are too much of a hassle (correct me if I’m wrong, rest of world).

> Huh? I'm saying solo ML-DSA causes definite security damage compared to
> ECC+ML-DSA. See https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys
> for quantification of the number of breakable keys. If you're not
> disputing this damage, how do you claim that ECC+PQ is "not worth it”?

See above, which also answers this question.

> Sorry, did I miss someone arguing _against_ better testing? My paper
> gives concrete examples of how unsatisfactory current testing is, and
> recommends various improvements.

Go ahead and work on them, then! Please release the djmldsa, the DJB ML-DSA test suite. I genuinely believe that everyone here will thank you for it!

> I prefer to put most of my testing efforts into more advanced test
> mechanisms that systematically cover larger classes of software flaws
> and are easier to scale to large volumes of code.

Fantastic! Do it!

> Anyway, obviously publishing ML-DSA best practices and high-quality
> ML-DSA code isn't going to instantly eliminate ML-DSA bugs from the
> software ecosystem. In software more broadly, there's a long history of
> best-practices documents and high-assurance software, and yet _typical_
> software is full of bugs.

All the more reason to get started today!

I’m telling you: if you want to help, this is what you should do! You really remind me of myself. Remember how last year I was so upset at the IACR for their biased public statements on the war? I was so angry and I kept getting upset at everyone, until I finally had the guts to grow up and go back to Lebanon and teach, and then my whole life changed! I found a way to turn my anger into something beautiful that helped those around me. Maybe this is what you need to do here! Instead of sending nonstop emails to the TLS mailing list (IACR board), go work on your super amazing ML-DSA/ML-KEM test/verification/best-practice effort (my course in Lebanon which starts again next week, admitting its one hundredth student, hard to type this without choking up), and direct this energy into THAT instead of these very long emails which have very much exhausted their contributions to society!

Think about this! Go do it!!!!

Nadim Kobeissi
Symbolic Software • https://symbolic.software

> On 3 Jun 2026, at 2:15 PM, D. J. Bernstein <[e-mail]> wrote:
> 
> Nadim Kobeissi writes:
>> But you're shifting the goalposts.
> 
> No, I'm not. See, e.g.,
> 
>    https://web.archive.org/web/20260603074058/https://mailarchive.ietf.org/arch/msg/spasm/pcISUlnedpExwwLuISP18oR1zxc/
> 
> for a 2024 posting where I emphasized how the risks of "bugs in
> post-quantum software" warrant "a blanket rule of always upgrading from
> ECC to PQ+ECC, _not_ discarding the ECC layer, even when the PQ layer is
> SPHINCS+" (which is the most conservative signature system).
> 
> In the same posting, I explained the difference between state-of-the-art
> bug elimination and what happens in the real world. What my new paper is
> doing is adding quantification of bug rates and exploitation costs in
> the case of ML-DSA, culminating in a concise graph
> 
>    https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys
> 
> with estimates for the number of breakable keys; but conceptually this
> is the same point I've been making for years.
> 
>> First, it was: "we don't know if
>> ML-DSA is a mature or sufficiently studied cryptographic design."
> 
> This quote (which is not from me) downplays (1) the instability of
> lattice security levels and (2) the further risks that come from the
> ML-DSA attack surface _beyond_ general lattice attacks. My new paper
> cites some examples of broken lattice systems and recent attack
> advances: see https://cr.yp.to/papers/mldsa-20260601.pdf#mathdenial.
> 
> The explicit reason that my new paper focuses primarily on bugs,
> omitting the risk of spec breaks from the estimates of the number of
> breakable keys, is that we _know_ bugs will happen. Even if the ML-DSA
> spec's security level someday stabilizes without much more security loss
> compared to today, we will see severe vulnerabilities in ML-DSA
> software---which will produce many more breakable ML-DSA keys than
> breakable ECC+ML-DSA keys.
> 
> Here are the main steps in how my paper quantifies this:
> 
>    * The 2021 Blessing--Specter--Weitzner study found that NSS added a
>      CVE for each ~2200 lines of added code; that OpenSSL added a CVE
>      for each ~840 lines of added code; that about 1/3 of CVEs across
>      OpenSSL, GnuTLS, NSS, Botan, Libgcrypt, wolfSSL, LibreSSL, and
>      BoringSSL were severe; and that about 1/8 of "cryptographic" CVEs
>      were severe.
> 
>    * In, e.g., OpenSSL the software for the ML-DSA primitive per se
>      has 2331 lines of portable code plus 1360 lines of Perl generating
>      AVX2-optimized NTT code. There are many more ML-DSA libraries, and
>      one expects roughly 1/4 of them to have severe vulnerabilities,
>      given the data regarding previous cryptographic CVEs.
> 
>    * My paper systematically analyzes various reasons that one might
>      optimistically hope for ML-DSA code to avoid bugs, or to avoid
>      vulnerabilities, or to avoid severe vulnerabilities. The paper
>      goes through examples of the endless bug opportunities for ML-DSA,
>      presents fast exploit demos for two examples, and looks at the
>      bugs that we've already seen in real software---including one of
>      the targets of the exploit demos.
> 
>    * My paper also quantifies how many ECC keys will be breakable by
>      quantum computers and through ECC software vulnerabilities.
> 
> Quoting Section 1: "The main conclusion is that far fewer Ed25519+ML-DSA
> keys will be breakable than ML-DSA keys, not just before the first
> quantum attack but also continuing for years after the first quantum
> attack. This conclusion is robust against uncertainties in the
> underlying numbers, such as bug rates."
> 
>> I'm pretty sure that there's some nineteen year old kid somewhere
>> writing his first ML-DSA implementation in JavaScript
> 
> That's not a reasonable characterization of the libraries with CVEs or
> other bugs announced in 2026 so far for Dilithium/ML-DSA code:
> 
>    * libgcrypt (CVE-2026-41990),
>    * wolfSSL (CVE-2026-3503 plus eprint 2026/1032),
>    * RustCrypto (CVE-2026-22705 plus CVE-2026-24850), and
>    * libcrux (the two bugs pointed out in your paper).
> 
> Appendix B of my paper explicitly discounts CVEs that mention ML-DSA but
> are actually in other code, such as CVE-2025-15469 (announced in 2026),
> in which "The 'openssl dgst' command-line tool silently truncates input
> data to 16MB when using one-shot signing algorithms and reports success
> instead of an error". But this CVE, like many others, illustrates that
> cryptographic libraries have a long way to go in quality assurance.
> 
>> It's never been my opinion that ECC+ML-DSA is bad or undesirable. My
>> opinion is that it's *just not worth it*. You'd need to add
>> hybridization scaffolding for signatures, something which currently
>> doesn't exist and isn't even specified, across every single TLS
>> implementation.
> 
> Huh? I'm saying solo ML-DSA causes definite security damage compared to
> ECC+ML-DSA. See https://cr.yp.to/papers/mldsa-20260601.pdf#breakable-keys
> for quantification of the number of breakable keys. If you're not
> disputing this damage, how do you claim that ECC+PQ is "not worth it"?
> 
> As a factual matter, there's already a spec. The added combiner code
> (sign twice, make sure both verify) needed per implementation is much
> smaller than the added ML-DSA code needed per implementation.
> 
>> the implementations that matter (i.e. whatever all major web browsers
>> and web servers use)
> 
> Are you sure you aren't underestimating the software diversity of web
> servers? See, e.g., the range of software listed in some TLS CVEs:
> 
>    https://cr.yp.to/papers/pqconnect-20241206.pdf#page.1
> 
> The damage done if IETF endorses solo ML-DSA in TLS includes a long tail
> of security problems that will take many years to clean up, very much
> like the damage done by IETF endorsement of RSA-512 and DSA-512 a long
> time ago:
> 
>    https://publish.illinois.edu/science-of-security-lablet/files/2016/08/10062016-Heninger-Slides.pdf
> 
> I'm horrified at the notion that the only damage we're concerned with is
> damage to Google etc. This violates an IETF principle that was quoted as
> "fundamental" in
> 
>    https://www.ietf.org/blog/ietf-llc-statement-competition-law-issues/
> 
> namely: "IETF participants use their best engineering judgment to find
> the best solution for the whole Internet, not just the best solution for
> any particular network, technology, vendor, or user."
> 
>> I don't think that ECC implementations are somehow less likely to have
>> bugs or are less in need of best practices and tons of testing!
> 
> See https://web.archive.org/web/20260603090502/https://mailarchive.ietf.org/arch/msg/last-call/0TJ297MxKhTJ4gonXr2H86xLi-8/
> for three quotes from my paper explaining flaws in this argument.
> 
> In short: (1) My paper shows that the usual ECC bugs have ML-DSA
> analogues, while the opposite isn't true. (2) ECC code is typically much
> older than ML-DSA code, so each ECC bug is more likely to have been
> eliminated. (3) Claiming that ML-DSA would have as few keys broken as
> ECC doesn't change the fact that ECC+ML-DSA will have fewer keys broken.
> 
>> The right thing to do right now is to improve our best practices and
>> make sure they reach as many implementations as possible
> 
> Sorry, did I miss someone arguing _against_ better testing? My paper
> gives concrete examples of how unsatisfactory current testing is, and
> recommends various improvements.
> 
>> Dan, why don't you for example try to contribute tests and other such
>> artifacts to projects like Wycheproof,
> 
> Wycheproof has been around for a decade. It added ML-DSA tests a year
> ago. Nevertheless various CVEs appeared in 2026 for released ML-DSA
> software. How do you explain that?
> 
> Here's my explanation: The bug coverage in Wycheproof is very far from
> comprehensive, as illustrated by bugs often leading to patches not just
> in buggy libraries but also _patches in Wycheproof_. Furthermore, people
> writing ML-DSA software often don't end up using Wycheproof, either
> because they didn't hear about it or because they have trouble using it.
> Furthermore, we're starting to see timing attacks in ML-DSA CVEs, and
> addressing those definitely needs more than just test vectors.
> 
> I prefer to put most of my testing efforts into more advanced test
> mechanisms that systematically cover larger classes of software flaws
> and are easier to scale to large volumes of code.
> 
> I don't mean to criticize people who are writing tests for specific
> bugs---I sometimes write those types of tests too. But there's a
> tradeoff between spending time on addressing specific bugs and spending
> time on addressing the underlying systemic issues.
> 
>> or if you're like me and prefer
>> to work alone, publish your own guidelines for ML-DSA best practices,
>> or even write your own ML-DSA implementation that you consider to be a
>> gold standard in terms of implementation quality and correctness for
>> others to emulate?
> 
> The core reason is that I see one application after another where KEMs
> are a better choice than signatures for authentication. We're using KEMs
> anyway for encryption, so eliminating signatures gets rid of a bunch of
> unnecessary risks in these applications. So I'm looking mainly at KEMs
> and symmetric cryptography. Here's an example of production code that I
> released a few months ago for an important subroutine, so you can get an
> idea of what I think is a reasonable level of quality assurance:
> 
>    https://sorting.cr.yp.to
> 
> Obviously signatures are important for _some_ applications, such as
> offline code signing. But offline code signing can trivially afford
> SPHINCS+. Security is a higher priority than efficiency.
> 
> What about applications that need offline signatures _and_ really can't
> afford SPHINCS+? There's XMSS and smaller variants of SPHINCS+. State
> management and limits on the number of signatures are risky, but not as
> risky as ML-DSA.
> 
> Maybe the ML-DSA picture settles down to something comfortable at some
> point. But then why would people not end up using one of ML-DSA's
> smaller successors, such as HAETAE? Is the cliff supposed to stop
> crumbling with ML-DSA exactly at the edge, the smallest unbroken
> lattice-based signature system? Seems implausible.
> 
> Anyway, obviously publishing ML-DSA best practices and high-quality
> ML-DSA code isn't going to instantly eliminate ML-DSA bugs from the
> software ecosystem. In software more broadly, there's a long history of
> best-practices documents and high-assurance software, and yet _typical_
> software is full of bugs.
> 
> ---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.