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
