> In other words, does CNSA 2.0 tolerate ECC, by effectively ignoring its presence, or not?
>From https://www.ietf.org/archive/id/draft-becker-cnsa2-tls-profile-00.html: "In order to meet the goal of a consistent security level for the entire cipher suite, CNSA TLS implementations MUST only use the algorithms listed in this document." That's ML-KEM-1024 and ML-DSA-87 only. On Tue, Nov 19, 2024, 4:52 PM Andrey Jivsov <cry...@brainhub.org> wrote: > Thank you for your replies, but please allow me to explore this. > > My primary question is whether a system signing a message M with both > ML-DSA-87 and an ECC method, where a clear 'path' exists tracing the > message to the ML-DSA-87 signature, would lose CNSA 2.0 compliance just > because there is some other signature somewhere. In other words, does CNSA > 2.0 tolerate ECC, by effectively ignoring its presence, or not? Is there > any reasoning that the presence of an additional and independent ECC > signature could somehow undermine the validity or security of the ML-DSA-87 > signature? > > My interest in this extends beyond TLS. Many systems, including TLS in > constrained environments, often need to commit to a single security > configuration. This raises questions about how to balance such constraints > with compliance. > > The vast majority of vendors and developers implementing TLS or protocols > inspired by its design are not exclusively targeting NSS use. These > providers are hearing concerns about the long-term security of ML-DSA. I > thought that the only practical way to address these concerns while > maintaining CNSA 2.0 compliance is to support signing with both ML-DSA and > ECC (or RSA). > > There is precedent in the FIPS 140 program where the use of non-approved > cryptographic primitives is categorized as either encoding (e.g., > unapproved encryption, compression) or as additional security-irrelevant > data (e.g., unapproved signatures, CRCs), such that this categorization > does not affect security associated with other approved crypto primitives. > > Since we are discussing products not exclusive to NSS use, these products > will include pure ECC and composite ML-DSA + ECC options. If, in addition, > CNSA 2.0 mandates the inclusion of pure ML-DSA, which adds to system > complexity. Some lesser-known protocols are addressing concerns with ML-DSA > in CNSA 2.0 by even more complex solutions than composite signatures: by > signing messages with two certificates -- one using ML-DSA and another > using ECC. Their rationale is, apparently, that a single ML-DSA X.509 > certificate signature clearly satisfies CNSA 2.0 compliance requirements. > Is this approach not a hybrid in CNSA 2.0? If dual signature with 2 X.509 > certs is a hybrid, CNSA 2.0, effectively, prohibits non-NSS use of a > "seatbelt" with ECC in environments that cannot support configurable > crypto, e.g. boot chain security with code in ROM. > > On Tue, Nov 19, 2024 at 8:15 AM aebe...@uwe.nsa.gov <aebe...@uwe.nsa.gov> > wrote: > >> 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> 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> 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 >> <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 >> 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 >> >>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
