> > 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.
CNSA 2.0, as clarified in a recent FAQ, does not prohibit ML-DSA+ECC. On Mon, Nov 18, 2024 at 5:54 AM Alicja Kario <hka...@redhat.com> wrote: > 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 > > _______________________________________________ > TLS mailing list -- tls@ietf.org > To unsubscribe send an email to tls-le...@ietf.org >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
