(and AES-256-GCM) On Tue, Nov 19, 2024, 5:11 PM Deirdre Connolly <durumcrustu...@gmail.com> wrote:
> > 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
