On Sat, May 23, 2026 at 06:36:34AM -0000, D. J. Bernstein wrote:
> There were only 37 people stating support (even _after_ vote-packing
> by NSA and its "vendors"), versus 14 people stating objections.
I don't believe that you're suggesting a plausible NOBUS secret in the
design of ML-DSA, that allows only NSA to break the algorithm even
after the underlying weakness is discovered.
The risk is therefore, that at some point the algorithm can be broken by
*anyone*, not just NSA. In that case, I see no incentive for NSA to
promote adoption of the algorithm not just by foreign actors, but also
by US entities, including the US government. If/when such a weakness
inevitably becomes public, much of the damage would have been incurred
by US entities (or in general by more open societies).
In that light, it seems a stretch to suggest that ML-DSA is being
foisted on the industry by NSA as part of their surveillance mission.
Perhaps NSA are just naïvely optimistic in their evaluation of the
ML-DSA algorithm, and foolishly believe it to be strong enough to
protect US (and in particular USG) traffic. That's certainly a position
you might take, but it is not surprising that many would not find it
very compelling.
Perhaps NSA are largely realists, but their risk evaluation skews much
more strongly towards timely mitigation of classical algorithm failure,
to which they assign a significant probability, much higher than that of
ML-DSA failure. If the classical component of the hybrid is expected to
fail long before ML-DSA does, there's little value in fielding a hybrid.
In that case, you're arguing that the IETF should adopt a risk profile
that is much more conservative than that of NSA, with less weight
attached to the probability of near-term failure (CrQCs appearing)
of classical algorithms, and more weight attached to the probability
of ML-DSA failure (an algorithm that might yet fall to novel attacks).
If CrQCs take much longer to appear than recent (circa 2029) speculative
timeframes suggest, and in that extended timeframe ML-DSA falls to novel
cryptanalysis, you'd be proved right. But NSA will then have egg on
their face, not because their subterfuge got unmasked, but because their
security assessment of ML-DSA was faulty.
Bottom line, I think you do your argument a disservice by dragging in
the NSA bogey man as a reason why ML-DSA should not be standardised in
the IETF. By all means, make a case that your risk profile is the more
prudent one, and/or that there's no consensus risk-profile.
My personal take is that an RFC defining ML-DSA in TLS is a how-to
document, not a whether-to document, and that risk profile choices
should not gate publication.
FWIW, I've been supportive of including security considerations that
make the risk-tradeoff explicit, but with or without such language, also
supportive of publication, because I don't see that any of the Sturm und
Drang will make much difference, other than to the reputation of the
IETF. The codepoints are assigned, the algorithm is in use, and,
unless/until a significant failure or a much better alternative is found,
the use of ML-DSA will grow (e.g. it is reportedly now in Chrome canary).
--
Viktor. 🇺🇦 Слава Україні!
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
