[TLS] Re: ML-DSA in TLS

To clarify, my draft I linked to (and future profiles) are instantiations of the CNSA 2.0 advisory and FAQ as it applies to specific protocols relevant to NSS; specifically, the drafts document how we expect vendors to configure protocols in a CNSA 2.0 compliant way. Thanks, that’s interesting

[TLS] Re: ML-DSA in TLS

The question at hand is whether CNSA 2.0 will _tolerate_ ECC+PQ (of course assuming the PQ algorithm is on the CNSA 2.0 list). Some people seem to think that purchasers under NSA control won't buy ECC+PQ products unless the ECC part is removed, and therefore the TLS WG has to adopt PQ along with E

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

I did notice one odd thing about the TLS-LTS protocol change (keep in mind this document is *not* deployment considerations, but a whole new incompatible mode for TLS 1.2), regarding domain separation. Unless TLS LTS can fully enforce that the same key is never used for TLS 1.2 LTS and regular TLS

[TLS] Re: ML-DSA in TLS

Hi all! To clarify, my draft I linked to (and future profiles) are instantiations of the CNSA 2.0 advisory and FAQ as it applies to specific protocols relevant to NSS; specifically, the drafts document how we expect vendors to configure protocols in a CNSA 2.0 compliant way. Cheers, Alie

[TLS] Re: ML-DSA in TLS

Given that the series of Suite B RFCs were Informational, it stands to reason that a document of the type that e.g. prohibits hybrids because of internal policies of any organization, a viewpoint which is not strongly shared by IETF, should not be a standards-track document. For what I see, no-hybr

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

-1. The TLS working group, and this document in particular, has consistently ignored the products of the UTA working group. Specifically, RFC 9325 [1] published a mere two years ago is not even referenced in the draft, let alone a comparison made with these deployment recommendations that were made

[TLS] Re: ML-DSA in TLS

Alicja Kario writes: > Or: > Auditor sees that P + Q system is more complex to implement and validate > than a simple Q system, therefore ML-DSA security > ML-DSA+Ed25519 security. Therefore the deployment of CECPQ2b = ECC+SIKE should have been replaced with just SIKE? What's next, advocating the

[TLS] Re: ML-DSA in TLS

On Tuesday, 19 November 2024 12:19:06 CET, D. J. Bernstein wrote: Alicja Kario writes: We can't use hybrid if we don't have a specification how to put hybrid keys into X.509 certificates. Take a specification of how to put a Dilithium key into certificates. Modify the spec as follows: replace

[TLS] Re: ML-DSA in TLS

https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF includes the following note: "Even though hybrid solutions may be allowed or required due to protocol standards, product availability, or interoperability requirements, C

[TLS] Re: ML-DSA in TLS

On Wed, Nov 20, 2024 at 6:06 AM D. J. Bernstein wrote: > > https://web.archive.org/web/20240925031754/https://media.defense.gov/2022/Sep/07/2003071834/-1/-1/0/CSA_CNSA_2.0_ALGORITHMS_.PDF > includes the following note: "Even though hybrid solutions may be > allowed or required due to protocol sta

[TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support

+1, especially given the previous discussion on this topic on the list back in 2016. Andrew -Original Message- From: Salz, Rich Sent: 05 November 2024 19:01 To: Sean Turner ; TLS List Subject: [TLS] Re: Adoption call for TLS 1.2 Update for Long-term Support I strongly support adopt

[TLS] Re: ML-DSA in TLS

> 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