Because there are other drafts for the other ideas.
Standardizing how to do ML-DSA in TLS in no way “favors” it or otherwise indicates any sort of exclusivity. There is nothing in the draft that precludes other approaches. -Tim From: Andrey Jivsov <cry...@brainhub.org> Sent: Friday, November 15, 2024 12:39 PM To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Cc: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>; tls@ietf.org Subject: [TLS] Re: ML-DSA in TLS I am curious why this draft exclusively proposes ML-DSA, instead of adopting a composite signature approach as outlined in draft-ounsworth-pq-composite-sigs, at least as an option. For instance, id-MLDSA87-ECDSA-P384-SHA512 defined in the draft aligns with CNSA 2.0. Could supporters of the draft elaborate on the rationale to favor or exclusively offer (?) a standalone ML-DSA? Or, will a hybrid ML-DSA be in another draft? On Fri, Nov 15, 2024 at 9:13 AM John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org <mailto:40ericsson....@dmarc.ietf.org> > wrote: >I'm unenthusiastic but don't strongly oppose adoption of this and >similar drafts, mostly because I think we should try get some WG >consensus on guidance for when these things may be needed (if ever) >and what the consequences might be should people deploy 'em in the >meantime. (By 'em I mean anything with any kind of PQ sig or non >hybrid PQ key exchange.) That guidance might or might not be in a >separate document, or be copied into each relevant one. More discussion would certainly be welcome. IPSECME is discussing what the right solution for hybrid PQC authentication is. The two proposals are composite public keys and signatures in a single certificate chain vs. two certificate chains. Both approaches have benefits and disadvantages. TLS should have the same discussion. Using two certificate chains is already possible in TLS with Post-Handshake Certificate-Based Client Authentication. Post-Handshake Certificate-Based Server Authentication should be added anyway as it is needed for long lasting TLS connections in infrastructure. WebPKI might want to wait but the many infrastructure use cases of TLS, DTLS, and QUIC need to migrate very soon. US government new requirement is that pure RSASSA, ECDSA, and EdDSA are forbidden from after 2035. European countries have similar recommendations/requirements. Country to an earlier comment on the list, industry does not like new shiny tools, to the contrary, industry loves using existing stuff if possible. https://csrc.nist.gov/pubs/ir/8547/ipd https://cyber.gouv.fr/sites/default/files/2021/03/anssi-guide-mecanismes_crypto-2.04.pdf >but don't strongly oppose adoption Please don’t. TLS is already seen as being behind LAMPS, IPSECME, and JOSE. Any further delay would likely end up in a lot of LSs from various infrastructure SDOs urging IETF to specify quantum-resistant authentication in TLS ;) Cheers, John From: Stephen Farrell <stephen.farr...@cs.tcd.ie <mailto:stephen.farr...@cs.tcd.ie> > Date: Friday, 15 November 2024 at 17:46 To: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org <mailto:40cloudflare....@dmarc.ietf.org> >, tls@ietf.org <mailto:tls@ietf.org> <tls@ietf.org <mailto:tls@ietf.org> > Subject: [TLS] Re: ML-DSA in TLS On 15/11/2024 10:51, Bas Westerbaan wrote: > We have posted a -00. > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-tls-westerbaan-mldsa-00 > <https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00> > &data=05%7C02%7Cjohn.mattsson%40ericsson.com%7Cb8e9b9505c8a47465c1308dd0594fae8%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638672859618372708%7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdata=CHrEsED8VIB%2FotGnx3i8Es%2BHyquLY6NZAxAaTz8ANnM%3D&reserved=0 I'm unenthusiastic but don't strongly oppose adoption of this and similar drafts, mostly because I think we should try get some WG consensus on guidance for when these things may be needed (if ever) and what the consequences might be should people deploy 'em in the meantime. (By 'em I mean anything with any kind of PQ sig or non hybrid PQ key exchange.) That guidance might or might not be in a separate document, or be copied into each relevant one. Cheers, S. _______________________________________________ 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>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
