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
