Hi Scott, Ekr, Good points. In the telecom industry, which is seen as critical infrastructure, we do not have time and we use TLS/DTLS/QUIC for a large number of interfaces. We already have governments and customers telling us that all public-key crypto should be quantum-resistant by 2030. I would like to see ML-DSA registration in some form asap. As scott says, this draft is very straightforward. Maybe the best thing is to make IANA registrations (Recommended = N) soon and then continue the discussion.
I agree that we should have hybrids and that we need more discussion regarding hybrids. That is more complex than hybrid key exchange. I would like to see SLH-DSA in TLS, especially for use as conservative root-of-trust. I have gotten the understanding, see e.g., [1-2], that the WebPKI might wait for FN-DSA or wait even longer for something like MAYO, UOC, HAWK, and SQISign. I like that there is a lot of discussion of PQC sizes, which are problematic. NIST's ramp-on triggers a lot of research on small PQC signatures. I hope that academic research on KEMs (or full DH replacements) with smaller sizes also continue. [1] https://blog.cloudflare.com/pq-2024/ [2] https://dadrian.io/blog/posts/pqc-signatures-2024/ Cheers, John From: Scott Fluhrer (sfluhrer) <sfluhrer=40cisco....@dmarc.ietf.org> Date: Thursday, 24 October 2024 at 05:15 To: Eric Rescorla <e...@rtfm.com>, John Mattsson <john.matts...@ericsson.com> Cc: Bas Westerbaan <b...@cloudflare.com>, <tls@ietf.org> Subject: RE: [TLS] Re: ML-DSA in TLS 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
