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
