> > 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> 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> 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> >>>>>> *Date: *Wednesday, 23 October 2024 at 19:59 >>>>>> *To: *Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> >>>>>> *Cc: *<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 >>>>>> To unsubscribe send an email to tls-le...@ietf.org >>>>>> _______________________________________________ >>>>>> TLS mailing list -- tls@ietf.org >>>>>> To unsubscribe send an email to tls-le...@ietf.org >>>>>> >>>>>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
