On Fri, 15 Nov 2024 at 23:10, Andrey Jivsov <cry...@brainhub.org> wrote:
> 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? > The hybrid ML-DSA draft (see https://datatracker.ietf.org/doc/draft-reddy-tls-composite-mldsa/) was published before the standalone ML-DSA and we published a revised draft to address the comments from the WG. -Tiru > On Fri, Nov 15, 2024 at 9:13 AM John Mattsson <john.mattsson= > 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> >> *Date: *Friday, 15 November 2024 at 17:46 >> *To: *Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>, tls@ietf.org >> <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&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 >> <https://datatracker.ietf.org/doc/html/draft-tls-westerbaan-mldsa-00> >> >> 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 >> 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
