[TLS] Re: ML-DSA in TLS

[Alicja Kario <[e-mail]>]

Answering to the broader thread: when I said "uncontroversial" I was 
thinking
more about _how_ it should be done, not _if_ it should be used.

Answer to email below follows.

On Saturday, 16 November 2024 09:57:03 CET, D. J. Bernstein wrote:
> Watson Ladd writes:
>> Authentication is not like encryption.
>
> I presume that you're alluding to the following process: if the PQ
> signature system is broken, we revert to ECC signatures, and then the
> attacker doesn't benefit from forging the no-longer-accepted signatures
> (whereas we can't stop attackers from breaking previous ciphertexts).
>
> This process leaves computers completely exposed until they've reverted
> to ECC. Sure, some environments are fast to make changes, but some
> aren't. For comparison, using ECC+PQ in the first place avoids this
> security failure, and will make many people less hesitant to upgrade.
>
> The revert-in-case-of-disaster process also leaves computers completely
> exposed to PQ attacks that haven't come to the public's attention yet.
> Out of the 69 round-1 submissions to NIST, 33 have been publicly broken
> by now (see https://cr.yp.to/papers.html#pqsrc) with some of the
> attacks not published for years; is it so hard to imagine that
> large-scale attackers found some attacks before the public did?
>
> More broadly, conflating "no attacks have been published" with "no
> attacks are being carried out" is unjustified, an extreme form of
> availability bias. Occasionally there are leaks from attackers
> illustrating how much damage this mistake has done. Example:
>
>    
> https://www.washingtonpost.com/world/national-security/nsa-infiltrates-links-to-yahoo-google-data-centers-worldwide-snowden-documents-say/2013/10/30/e51d661e-4166-11e3-8b74-d89d714ca4dd_story.html

All good points, ones I agree with, but I think those are arguments
against wide deployment of pure ML-DSA, not against describing how
the algorithms should be implemented on technical level.

The reality is that we have very tight deadlines from CNSA2.0, with 
customers
actively asking for post-quantum support. For those for whom those 
requirements
apply, use of ML-DSA is not only uncontroversial, but mandatory.

And personally, I'd prefer them using ML-DSA than LMS or XMSS...

For the wider Internet, where we want fail-safe options, yes, hybrids are
probably better. Unfortunately, I don't think we have a rough consensus in
LAMPS on how hybrid signatures should be done just yet, and without that,
we can't standardise it for TLS.

(that being said, I don't think ML-DSA will be completely broken 
over-night,
I suspect it will be weakened over time, so migration off of it won't need
to happen with high agility... but only time will tell how it will play 
out)
-- 
Regards,
Alicja (nee Hubert) Kario
Principal Quality Engineer, RHEL Crypto team
Web: www.cz.redhat.com
Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic