Most likely, we’ll need both composite and pure ML-DSA cert chains. We have a set of customers who don’t trust pure PQC (yet?), and we have other customers who are determined to skip composite cert deployment.
* These are independent matters. Yes, pure and composite signature suites can be introduced via separate I-Ds. Cheers, Andrei From: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> Sent: Friday, October 25, 2024 8:28 AM To: Eric Rescorla <e...@rtfm.com> Cc: <tls@ietf.org> <tls@ietf.org> Subject: [EXTERNAL] [TLS] Re: ML-DSA in TLS I'm not sure I agree that there is no value. In general, we try to roll out new mechanisms slowly so that we get some experience with how they perform in the wild. Given the experience with PQ key establishment, we should probably have some concern that ML-DSA won't just work in all cases, and we'd like to find that out now, which requires some level of deployment. I am well aware, and we will, as we have before. But I think we've strayed from the original question you asked: 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. I think we should at least standardize pure ML-DSA. That does not prevent us from standardising a hybrid as well. These are independent matters. Best, Bas PS. Majority of testing can be done without hybrids. Don't run it on production traffic. Or pad a P-256 key to the length of ML-DSA. If it's compute we want to test, run a dummy ML-DSA verify. If we do want the full thing with a hybrid, we can use an ad hoc hybrid (as CECPQ2 was ad hoc too.) The proposal you sketch also requires an update at the time CRQCs are near to disable the non-PQ certificates. Absolutely. We're just in an asymmetrical position in that we're already exposed to the risk of non-PQ but not to the risk of PQ. -Ekr If you have a system that cannot have an update, then you indeed need a hybrid. In general, the client is exposed to the union of the risks of compromise of the signature algorithms it supports. Thus, in a world where the client supports: [ECDSA, ML-DSA], then compromise of either algorithm is an issue. By contrast, if the client supports [ECDSA, EC-DSA+ML-DSA], then compromise of ML-DSA alone is insufficient to result in an attack. This is of course the same logic that leads to hybrids for key establishment. An obvious response here is "if something goes wrong with ML-DSA, we'll just turn it off quickly". This is certainly true for browsers, but I'm less sure it's true for other systems. If you think that it takes a long time to disable algorithms, then it seems like that's an argument that hybrid signatures are safer. -Ekr [0] There is benefit in the servers supporting PQ ahead of time because the client will have to make a cost/benefit decision in terms of breakage, and the more servers support PQ, the easier this decision is. It's uncomfortable though if the first blessed SignatureScheme would be a non-hybrid. (Also regulators don't make the distinction between authentication and encryption, but at least most of them insist on hybrids for both though.) So I agree it makes sense to set recommended=N for now. Best, Bas On Thu, Oct 24, 2024 at 4:47 AM Eric Rescorla <e...@rtfm.com<mailto:e...@rtfm.com>> wrote: 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
