Hello, The code point for SecP384r1MLKEM1024 has been registered.
Please see https://www.iana.org/assignments/tls-parameters Happy New Year, Kris On December 11, 2024 2:38:59 PM GMT+01:00, Bas Westerbaan <b...@cloudflare.com> wrote: >Following the feedback from the last TLS meeting at IETF@121, I have opened >> this PR to change the name from X25519MLKEM768 to MLKEM768X25519. This >> change aligns with draft-ietf-tls-hybrid-design-11 (section 3.2). >> >> https://github.com/post-quantum-cryptography/draft-kwiatkowski-tls-ecdhe-mlkem/pull/26 >> > >I don't believe there was consensus to swap (or keep) the name. >X25519MLKEM768 has already been assigned and deployed under that name. > > >> 2. **Changing the order of shares in Secp256r1MLKEM768**. >> - The current order is based on requirements from SP800-56C-r2, and it >> was chosen to facilitate the migration of the TLSv1.3 >> handshake in a flow requiring FIPS certification. Although the >> switched order of shares aligns with FIPS, it necessitates >> the re-certification of the cryptographic module. The current order >> supports modules that are already deployed in the field. >> My (slight) personal preference would be to proceed with adoption but >> switch the order only if NIST relaxes the requirement >> regarding the order of shares in SP800-56C-r2, which we know is under >> discussion. Otherwise, I believe the current choice >> better supports migration to non-hybrid MLKEM, but I would appreciate >> feedback on this decision (ideally from others who >> have a requirement for FIPS). >> >> According to the message from >> https://groups.google.com/a/list.nist.gov/g/pqc-forum/c/ST_yMzYyMl0, NIST >> plans to permit the ordering of shares in either direction. This approach >> addresses the previously mentioned issue, so no further changes are needed >> in this regard. I believe it is now appropriate to register an additional >> code point for Secp384r1MLKEM1024, as currently outlined in the draft. >> >> >> 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**. >> >> I think this can only be done once draft if adopted. Hence, no change here >> (for now). >> > >Agreed. > > >> > On 11/11/2024 23:14, Andrei Popov wrote: >> > I support adoption. The question of explicitly prohibiting key share >> reuse is orthogonal; this can be done in a separate document. >> I agree that the PR was submitted to change the text in the draft, but I >> think it would be better to include this text in >> draft-ietf-tls-hybrid-design. I have opened this PR >> https://github.com/dstebila/draft-ietf-tls-hybrid-design/pull/39. >> > >LGTM. > >> With that I hope the draft is ready for adoption. >> > >Ageed. > >Thanks Kris, > > Bas
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
