Today for the WebPKI there is no security benefit to enabling post-quantum certificates (in stark contrast with post-quantum key agreement.) On the other hand, there is a big cost with extra bytes on the wire. As it stands, we do not intend to enable post-quantum certificates by default before the CRQC is near. At that point, there is little value in hybrid certificates. There is value in having post-quantum certificates ready-to-go now (without flipping the switch.) And for that pure ML-DSA makes more sense.
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
