Agree completely, the only thing that can go wrong with this draft is scope creep.
-Tim From: Deirdre Connolly <durumcrustu...@gmail.com> Sent: Wednesday, October 23, 2024 3:22 PM To: Alicja Kario <hka...@redhat.com> Cc: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org>; <tls@ietf.org> <tls@ietf.org> Subject: [TLS] Re: ML-DSA in TLS I would rather have a separate I-D for anything beyond ML-DSA (and thanks, this is great!) On Wed, Oct 23, 2024 at 2:13 PM Alicja Kario <hka...@redhat.com <mailto:hka...@redhat.com> > wrote: On Wednesday, 23 October 2024 20:01:28 CEST, John Mattsson wrote: > Let’s have an adoption call asap. > > I made some minor suggestions > https://github.com/bwesterb/tls-mldsa/pull/3 good catch on the signature_algorithms_cert part! and on that front, I wonder if we shouldn't also include SLH-DSA codepoints as those may be used by the CA certs, even if the EE use ML-DSA... or make it a separate I-D? > John > > From: Alicja Kario <hka...@redhat.com <mailto:hka...@redhat.com> > > Date: Wednesday, 23 October 2024 at 19:59 > To: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org > <mailto:40cloudflare....@dmarc.ietf.org> > > Cc: <tls@ietf.org <mailto: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 >> <https://bwesterb.github.io/tls-mldsa/draft-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: www.cz.redhat.com <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 <mailto:tls@ietf.org> To unsubscribe send an email to tls-le...@ietf.org <mailto:tls-le...@ietf.org>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
