> 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.
💯% agree. > 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.) I don't necessarily agree but, sure whatever > So I agree it makes sense to set recommended=N for now. ++ Doing the same for pure ML-KEM SupportedGroup codepoints too. On Thu, Oct 24, 2024 at 3:39 AM Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> wrote: > 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
