I'm a member of the SPHINCS+ team but am speaking for myself here: I
don't think it was a good idea for the WG to jump into signatures at
this point. However, given that the WG is considering risky ML-DSA for
signatures, the WG should also adopt safer options for signatures.
Using the risks of ML-KEM as an argument to accept the risks of ML-DSA
(and, presumably, vice versa) reminds me of the argument that encrypting
SNI is useless since DNS leaks the same information (and vice versa).
One systems-level answer to such arguments is to work on fixing both
pieces (e.g., encrypt SNI _and_ DNS). But one should also ask whether
the arguments are accurately assessing security in the first place.
For example, are people conflating ML-KEM breaks with ML-DSA breaks?
General advances in lattice attacks have been damaging the security of
both ML-KEM and ML-DSA, but a proper risk assessment has to ask about
(1) general lattice cryptanalysis _and_
(2) specific cryptanalysis of ML-KEM _and_
(3) specific cryptanalysis of ML-DSA _and_
(4) implementation failures.
There haven't been many papers that go beyond #1 to #2 and/or #3. The
exceptions such as https://eprint.iacr.org/2025/1176 are showing ways
that #2 is different from #3: in particular, Dilithium's reliance on an
ad-hoc "self-target" problem is starting to look like something that
damages security. There are also more performance complaints about
ML-DSA than about ML-KEM, so ML-DSA seems less likely than ML-KEM to
have people reducing #1/#2/#3 risks by moving up to bigger key sizes.
As for #4, remember how the KyberSlash attack demos rely on keys being
reused, triggering comments such as "KyberSlash does not affect Kyber as
it is used in TLS"? Even if every ML-DSA implementation flaw turns out
to be an ML-KEM implementation flaw too (despite large differences in
the software), typical key lifetimes will be longer for ML-DSA, which
can easily make the difference between exploitable and non-exploitable.
I wouldn't say that the risks of ML-KEM and ML-DSA are orthogonal:
again, both of their security levels have been dropping because of
general advances in lattice attacks. But ML-DSA also has its own risks,
and addressing those has security value even inside a protocol that's
(unnecessarily) set up to fail whenever ML-KEM fails.
> > But how are you concluding that TLS using ML-KEM and SLH-DSA has risk as
> > high as TLS using ML-KEM and ML-DSA?
> I'm not concluding that, Dan.
Sorry if I misunderstood---but now I'm even more puzzled as to what the
rationale is supposed to be for the claim that there's "little value in
using SLH-DSA over (hybrid) ML-DSA unless you also use a different key
agreement".
The basic reason people are interested in SLH-DSA is because of risk
evaluations saying that SLH-DSA has lower risk than ML-DSA. You don't
seem to be disputing this.
Instead you seem to be saying (please correct me if I'm misunderstanding
something) that this doesn't translate into a lower overall TLS risk if
it isn't combined with a lower-risk KEM than ML-KEM.
That's the part that's puzzling me. To me, it sounds like a claim that
TLS using ML-KEM and SLH-DSA has risk as high as TLS using ML-KEM and
ML-DSA. But (1) I don't see the justification for such a claim and (2)
you're now saying that you _aren't_ claiming this. But then what _are_
you claiming?
---D. J. Bernstein
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
