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 >>> <https://www.google.com/maps/search/Purky%C5%88ova+115,+612+00,+Brno,+Czech+Republic?entry=gmail&source=g> >>> >>> _______________________________________________ >>> 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
