On Fri, Nov 15, 2024, 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. > Authentication is not like encryption. Why do you need two chains vs having a backup algorithm? > > > 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
