In my opinion, we’ll end up standardizing both. At the very least, I (Cisco) have some customers who want ML-DSA only, and other customers that insist on hybrid, and so we’ll need to support both.
Standardizing ML-DSA only appears to be straightforward – we just need to assign some code words, and it “works”. Perhaps not as efficiently as we would like, with the largish ML-DSA certificates, but (IMHO) I believe that the optimization efforts can be done independently of the actual signature algorithm. Of course, when it comes to hybrid, we have some options to sort through. Do we: * Support a hybrid certificate (such as proposed in the LAMPS wg)? * Modify the TLS protocol to rely on multiple certificates (one of which might be a traditional RSA certificate and one an ML-KEM only certificate)? I can see reasons why either option makes sense; what does the working group think? From: Eric Rescorla <e...@rtfm.com> Sent: Wednesday, October 23, 2024 10:47 PM To: John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org> Cc: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>; <tls@ietf.org> <tls@ietf.org> Subject: [TLS] Re: ML-DSA in TLS I think an adoption call is a bit premature here. We've got some time, especially in the WebPKI setting. In particular, we should have a discussion of whether we want to standardize pure ML-DSA or hybrid ML-DSA/EC algorithms; I currently lean towards the latter, but I, at least, would like to hear arguments to the contrary. -Ekr On Wed, Oct 23, 2024 at 11:02 AM John Mattsson <john.mattsson=40ericsson....@dmarc.ietf.org<mailto:40ericsson....@dmarc.ietf.org>> wrote: Let’s have an adoption call asap. I made some minor suggestions https://github.com/bwesterb/tls-mldsa/pull/3 John From: Alicja Kario <hka...@redhat.com<mailto:hka...@redhat.com>> Date: Wednesday, 23 October 2024 at 19:59 To: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org<mailto:40cloudflare....@dmarc.ietf.org>> Cc: <tls@ietf.org<mailto:tls@ietf.org>> Subject: [TLS] Re: ML-DSA in TLS Hi, Thanks for the draft, will definitely be helpful. Few issues: * The range 0x0900-0x0903 is reserved for backwards compatibility I think it will be better to continue the numbering in the 0x08.. space * the must in "must use id_ML-DSA(...)" probably should be capitalised, as if it doesn't match, the connection needs to be aborted open question is if we should document error handling explicitly: - illegal_parameter alert if the peer used algorithm not advertised, or signature algorithm does not match the certificate - decrypt_error when verification of the signature failed On Wednesday, 23 October 2024 19:29:06 CEST, Bas Westerbaan wrote: > Hi all, > > Unless I overlooked something, we don't have a draft out to > assign a SignatureAlgorithm to ML-DSA for use in TLS. > > It's two days past the I-D submission deadline, but I wanted to > point you to a short draft we put together to fill this gap. > > https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbwesterb.github.io%2Ftls-mldsa%2Fdraft-tls-westerbaan-mldsa.html&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501883034%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=1oIREiL3cz5iRqrSRQ2PKnw5%2BdAkv89rBl9AnUJwAgs%3D&reserved=0<https://bwesterb.github.io/tls-mldsa/draft-tls-westerbaan-mldsa.html> > > So far, I see only one open question: whether to set a non-zero > context string. > > Best, > > Bas > > > -- Regards, Alicja (nee Hubert) Kario Principal Quality Engineer, RHEL Crypto team Web: https://eur02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.cz.redhat.com%2F&data=05%7C02%7Cjohn.mattsson%40ericsson.com%7C8fef63d5eddc4cb44fee08dcf38c63f4%7C92e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C638653031501906645%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=OEPmJIyNseoOyEubpjkOsGFhcqmd2HRTqwKcj4Xwkqk%3D&reserved=0<http://www.cz.redhat.com/> Red Hat Czech s.r.o., Purkyňova 115, 612 00, Brno, Czech Republic _______________________________________________ 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> _______________________________________________ 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>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
