I also support adoption. The draft has long been ready for it. The various details being discussed here sound like something that can be resolved after adoption. (Or in parallel since folks seem eager to discuss them now, but they need not block adoption.) Adoption is the start of the process, not the end.
On Wed, Dec 11, 2024 at 8:40 AM Bas Westerbaan <bas= 40cloudflare....@dmarc.ietf.org> 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 >
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
