Dear Dan, You write:
> 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? No, of course I don’t think that all ML-DSA libraries are following best practices! But you’re shifting the goalposts. First, it was: “we don’t know if ML-DSA is a mature or sufficiently studied cryptographic design.” Now, it’s “are you sure that every single ML-DSA library in the world won’t have bugs??” I’m pretty sure that there’s some nineteen year old kid somewhere writing his first ML-DSA implementation in JavaScript, and maybe it’ll be adopted by some cryptocurrency called CryptoDog or whatever and then CryptoDog will have massive vulnerabilities. It’s not reasonable to expect us to chase down every single implementation everywhere to try to avoid this scenario. > 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. 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. Given that signature compromise has to be on-the-fly during a TLS connection to have an impact, and given that, on the whole, ML-DSA seems fine and we are getting better at implementing it correctly, I think it’s not a horribly risky decision. ML-DSA implementations aren’t a untameable sea full of dark mythical creatures. They’re just a few thousand lines of code. I am confident that we can achieve best practice discipline for a library of this complexity such that these best practices are followed at least in the implementations that matter (i.e. whatever all major web browsers and web servers use) if not every single implementation in the world. And by the way, 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! We had a fair standardization process, ML-KEM and ML-DSA won, and we’re getting better at implementing them. I personally don’t like these primitives: ML-KEM’s public keys are too big, and ML-DSA’s public key and signature sizes are comically large, and I think they’re kind of annoying to implement. But what can we do? These were the best all-around designs that we could come up with in a relatively short time. The right thing to do right now is to improve our best practices and make sure they reach as many implementations as possible, and that happens through working together as a team to improve the security of all implementations! I am known (rightfully) for having trouble separating my personal feelings about topics from the professional, but here I think it may lead me to say something important: this fighting really breaks my heart. I think DJB is a genius who really pushed the field forward. Signal would’ve never developed triple Diffie-Hellman or the double ratchet on smartphones in ~2013 if it weren’t for Curve25519 making it bandwidth-efficient and performance-efficient to do Diffie-Hellman on smartphones. I also think that people like Soatok, Tony Arcieri, and (*takes a deep breath*) Filippo are highly competent cryptographic engineers with a lot to contribute in terms of paving the way for better implementations. I think scientists like Sophie Schmieg provide a fascinating independent take on a lot of topics that have certainly taught me a lot. I think Tanja Lange is a profoundly insightful mathematician. I think Bas Westerbaan is a very nice and insightful fellow as well who frequently writes excellent posts and articles that have certainly taught me a lot as well. All of this is to say that I really hate to see how much both camps here have been fighting. It really hurts. I’m often rude, too. I get offended, too. I say stupid things all the time, and get defensive, and attack people, and so on. It’s a fact of life and we all need to work on ourselves. But I don’t see *myself* as a super genius the way I see Dan and Tanja, and I don’t see *myself* as a master super implementer the way I see the others I mentioned above. I think you guys can all do better. Please try to work together. It will make you all happier. It will lead to a healthier community. Dan, why don’t you for example try to contribute tests and other such artifacts to projects like Wycheproof, 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? Soatok and Filippo, you could then for example review Dan’s best practice guide/implementation and try to help him polish it such that it’s useful for Rust and Go implementations as well as other languages (assuming that Dan writes his in C, which I think is his preferred language). Isn’t this a better way forward than nonstop insults? Having insulted many people myself, I’ve learned that it hurts the other person, but you also inflict pain on yourself by damaging your own soul. The world is a dark and awful place, often. A lot of us came to cryptography because it was the one place where we felt a sense of belonging, intellectual excitement, and empowerment. Let’s not make cryptography as ugly as the rest of the world! Sorry, I know this turned into a strange email, but these are my honest thoughts and I believe they are useful. Nadim Kobeissi Symbolic Software • https://symbolic.software > On 3 Jun 2026, at 1:13 AM, D. J. Bernstein <[email protected]> wrote: > > 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.
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
