On Fri, Oct 25, 2024 at 7:55 AM Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> wrote: > > 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.
There is a signature scheme secure if any signature scheme is secure. This fundamentally changes the risk. > >> >> 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 >>>>> > >>>>> > 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 >>>>> 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 -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
