Hi Eric,
> Hi Bas, > > I'm not sure I agree with this analysis, but perhaps it depends on > what you mean by "ready-to-go". > > I would think that the natural thing to do here is to get fairly > widespread deployment of support for PQ certificates but then prefer > non-PQ certificates. I.e., > > 1. Clients would support both PQ and non-PQ certificates. > 2. Servers would have both PQ and non-PQ certificates, but would > provide the non-PQ certificate if the client supported it. > > This would enable clients to decide that the risk from non-PQ was high > (as you say "the CRQC is near") and disable non-PQ. Note that it > doesn't matter whether the server supports non-PQ as well, as the > security benefit comes from the client refusing it [0]. Do we agree so > far? > Unless a CRQC is near, there is no value, only risk to advertise support for ML-DSA. Thus I'd say clients would add support, but not advertise it. That requires an update at the time CRQC are near. The proposal you sketch also requires an update at the time CRQCs are near to disable the non-PQ certificates. 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
