I do not support ML-KEM only.
On Mon, 11 Nov 2024 at 22:03, Deirdre Connolly <durumcrustu...@gmail.com> wrote: > > OK; what about ML-KEM only? > > On Mon, Nov 11, 2024, 9:58 AM Bas Westerbaan <b...@cloudflare.com> wrote: >> >> That was before the release of FIPS 203. >> >> On Mon, 11 Nov 2024 at 18:29, Deirdre Connolly <durumcrustu...@gmail.com> >> wrote: >>> >>> Two meetings ago there was a consistent vibe in the room that Recommend'ing >>> any PQ parameters, hybrid or no, was premature; has that changed? >>> >>> On Mon, Nov 11, 2024 at 9:00 AM Alicja Kario <hka...@redhat.com> wrote: >>>> >>>> On Sunday, 10 November 2024 13:38:38 CET, Kris Kwiatkowski wrote: >>>> > Hello, >>>> > >>>> > As discussed during the TLS session at IETF 121, we would like >>>> > to propose the adoption of draft-kwiatkowski-tls-ecdhe-mlkem. >>>> >>>> Very much in favour of adopting this draft. >>>> >>>> > There are a few open questions that need to be addressed: >>>> > >>>> > 1. **Alignment of NamedGroup X25519MLKEM768** with the order of >>>> > shared secrets, as per Section 3.2 of >>>> > draft-ietf-tls-hybrid-design. >>>> > - I suggest updating the name to mlkem768_x25519, while >>>> > keeping the codepoint unchanged (if that is acceptable). If >>>> > this change is made, I also recommend changing the name of >>>> > Secp256r1MLKEM768 to align with x25519. >>>> >>>> while I'd /like/ for the name to remain, I'm not opposed to changing it, >>>> especially if we make it so that the order in the name matches the order >>>> in the shares and derived secrets >>>> (I've already seen names all over the place for the codepoint, so the >>>> name isn't consistent across different implementations already...) >>>> >>>> no preference for mlkem768_x25519 vs MLKEM768X25519 vs mlkem768x25519 >>>> >>>> OTOH, if NIST doesn't change their stance, then having name represent the >>>> order, and there still being interest in hybrid at a time when P-256 and >>>> P-384 are not approved, would give a clear description for the new point, >>>> new name, with the order reversed >>>> >>>> Given how widely it is already deployed, I'm very strongly opposed to >>>> changing the codepoint or its meaning. >>>> >>>> > 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). >>>> >>>> I'm opposed to changing the order. The way it is right now (for all three >>>> codepoints) is good. Especially speaking as a vendor intersted in FIPS >>>> compliance. >>>> >>>> Even *if* NIST relaxes the requirements, we don't know *when* that will >>>> happen. >>>> We have explicit confirmation that as long as the first algorithm is >>>> FIPS approved, then the whole SP800-56Cr2 scheme is, so I think, for FIPS >>>> compliance, we're good. >>>> >>>> If in the future it will turn out that we want a hybrid with ML-KEM-1024 >>>> first, registering it won't be too much work. >>>> (Or NIST may say that ML-KEM is fine as the second one iff the first >>>> shared secret was "formely NIST approved algorithm", we don't know.) >>>> >>>> And even without it, we already have codepoints for pure ML-KEM of all >>>> sizes. >>>> >>>> So, I think the three codepoints are the minimal set to handle: >>>> * the general Internet >>>> * FIPS compliance >>>> * Common Criteria Protection Profile compliance >>>> >>>> with as little friction to roll them out as possible. >>>> >>>> I think this is the main thing we should have in mind: we want people >>>> using PQC key exchanges as soon as possible as widely as possible. >>>> >>>> > 3. **Setting RECOMMENDED=Y for Secp256r1MLKEM768**. >>>> >>>> Since all three (secp256r1, secp384r1, and x25519) are RECOMMENDED=Y, >>>> I think we should set "Y" for those three algorithms too. >>>> >>>> > Additionally, we plan to register Secp384r1MLKEM1024, but I >>>> > believe this should only be done once we reach a consensus >>>> > regarding >>>> > point 2. >>>> > >>>> > Thank you! >>>> >>>> -- >>>> Regards, >>>> Alicja (nee Hubert) Kario >>>> Principal Quality Engineer, RHEL Crypto team >>>> Web: 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
