The standalone ML-DSA-87 option specified in this draft is CNSA 2.0 compliant. There are no plans to support hybrid solutions for CNSA 2.0 (other than where required due to protocol constraints, such as during key establishment in IKEv2 as pointed out earlier in this thread). As such, our CNSA 2.0 TLS profile requires only standalone ML-KEM-1024, and ML-DSA-87; we recently posted an early version: https://datatracker.ietf.org/doc/draft-becker-cnsa2-tls-profile Cheers, Alie
________________________________ From: Deirdre Connolly <durumcrustu...@gmail.com> Sent: Monday, November 18, 2024 7:43 PM To: Andrey Jivsov <cry...@brainhub.org> Cc: D. J. Bernstein <d...@cr.yp.to>; TLS@ietf.org <tls@ietf.org> Subject: [TLS] Re: ML-DSA in TLS The CNSA 2.0 FAQ states, "Do not use a hybrid or other non-standardized QR solution on NSS mission systems except for those exceptions NSA specifically recommends to meet standardization or interoperability requirements", and, "because NSA is confident that CNSA 2.0 algorithms will sufficiently protect NSS, it does not require a hybrid solution for security purposes." They specifically cite IKEv2 as a hybrid exception. https://media.defense.gov/2022/Sep/07/2003071836/-1/-1/0/CSI_CNSA_2.0_FAQ_.PDF On Mon, Nov 18, 2024, 8:37 PM Andrey Jivsov <cry...@brainhub.org<mailto:cry...@brainhub.org>> wrote: 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<mailto: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<http://www.cz.redhat.com/> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic<https://www.google.com/maps/search/Purky%C5%88ova+115,+612+00,+Brno,+Czech+Republic?entry=gmail&source=g> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org> _______________________________________________ TLS mailing list -- tls@ietf.org<mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org<mailto:tls-le...@ietf.org>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
