I happen to think that standalone ML-DSA in TLS is a controversial issue. In practice, PQ authentication is not an immediate issue in a sense of "record now, decrypt later". We expect TLS servers to continue to be configured with RSA key pair (key+cert) and ECDSA key pair. We are talking about what the 3d key pair should look like.
In years to come TLS servers and clients will continue to negotiate RSA or ECDSA-based handshakes, as they are today. Some time in the future, there may be a need to switch to the 3d key pair. I fail to see what are the advantages of standalone ML-DSA for this use case. Is it marginal performance gain, at the expense of security, some years in the future? In addition, supporting pure ML-DSA and ML-DSA + ECC has complexity cost, interoperability is harder, etc. There is also an issue of what signatures in X.509 certs will look like. Especially in CA certificates, these may favor ML-DSA+ECC v.s. ML-DSA, so there would need to be support by TLS stack for the hybrid for that reason. Overall, it seems more productive to me to focus on ML-DSA hybrid in TLS. I am not opposed to ML-DSA only, but to me it would be secondary to ML-DSA hybrid. On Fri, Nov 15, 2024 at 9:53 AM Alicja Kario <hka...@redhat.com> wrote: > On Friday, 15 November 2024 18:38:56 CET, Andrey Jivsov 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? > > We will definitely need a second draft with hybrid ML-DSA definitions. > > The reason for pure ML-DSA is that for TLS use case, use of hybrids has > limited benefits. OTOH, we can be sure that for use cases like S/MIME > we will want clients that use hybrid algorithms, and we know that reusing > certificates for user authentication is quite common, so we will > need codepoints at the very least for clients. But then there's no point > in limiting it to clients only. > > So, the reason for this draft focusing on ML-DSA only is simplicity: > How to use pure ML-DSA is uncotroversial, both in certs and in signatures, > so we can release this standard quickly. > > > 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 > > > > 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. > > > > -- > Regards, > Alicja (nee Hubert) Kario > Principal Quality Engineer, RHEL Crypto team > Web: www.cz.redhat.com > Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic > >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
