>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
