* A few IETF ago we wanted to add codepoints to hybrid-design for X25519Kyber768Draft00, but the working group felt that a separate document was more appropriate. This makes sense, however shouldn’t draft-kwiatkowski-tls-ecdhe-mlkem-01 be on the Standards track? Also, what is the thinking behind “Recommended: N” for the code points?
From: Bas Westerbaan <bas=40cloudflare....@dmarc.ietf.org> Sent: Monday, September 9, 2024 2:05 PM To: Andrei Popov <andrei.po...@microsoft.com> Cc: Alicja Kario <hka...@redhat.com>; Kris Kwiatkowski <k...@amongbytes.com>; tls@ietf.org Subject: Re: [TLS] Re: [EXTERNAL] draft-kwiatkowski-tls-ecdhe-mlkem and P-384 On Mon, Sep 9, 2024 at 10:56 PM Andrei Popov <Andrei.Popov=40microsoft....@dmarc.ietf.org<mailto:40microsoft....@dmarc.ietf.org>> wrote: Yes, we need SecP384 hybrids. More generally, I see two separate hybrid key exchange drafts under discussion in the TLS WG: - draft-ietf-tls-hybrid-design-10 refers to pre-standard Kyber; - draft-kwiatkowski-tls-ecdhe-mlkem-01 defines hybrids with ML-KEM 768. The latter is merely an instantiation of the former. A few IETF ago we wanted to add codepoints to hybrid-design for X25519Kyber768Draft00, but the working group felt that a separate document was more appropriate. hybrid-design only mentions pre-standards Kyber, because it wasn't updated to reflect the release of ML-KEM. It doesn't define codepoints. Both drafts are on the Informational track. Do we really need two separate documents? Also, shouldn't this work be on the Standards track? Cheers, Andrei -----Original Message----- From: Alicja Kario <hka...@redhat.com<mailto:hka...@redhat.com>> Sent: Friday, September 6, 2024 4:40 AM To: Kris Kwiatkowski <k...@amongbytes.com<mailto:k...@amongbytes.com>>; tls@ietf.org<mailto:tls@ietf.org> Subject: [EXTERNAL] [TLS] draft-kwiatkowski-tls-ecdhe-mlkem and P-384 Hello, What's the situation with other groups for TLS 1.3? Specifically, are there any plans to specify SecP384r1MLKEM1024? As mentioned in multiple emails already, high security system already have a strict requirement to use P-384 curve exclusively. Similarly, for post-quantum resistance they will be required to use ML-KEM-1024. Will you add it to the draft, or should we start work on a separate one that defines those hybrid algorithms? -- Regards, Alicja (nee Hubert) Kario Principal Quality Engineer, RHEL Crypto team Web: 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> _______________________________________________ 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>
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
