Respectfully disagree with Alicja. There is no need to steer people towards hybrids.
For example, we don’t need hybrids (based on our understanding of cryptography/math and the quality of our crystal balls ;) and don’t intend to employ them. Others may prefer hybrids, and it’s fine with me. ;-) — Regards, Uri Secure Resilient Systems and Technologies MIT Lincoln Laboratory > On Nov 11, 2024, at 13:24, Alicja Kario <hka...@redhat.com> wrote: > > !-------------------------------------------------------------------| > This Message Is From an External Sender > This message came from outside the Laboratory. > |-------------------------------------------------------------------! > > I'd vote for "N": I worry about the security of implementations. > And I think we should steer people towards hybrids. > >> On Monday, 11 November 2024 19:00:01 CET, Deirdre Connolly 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 ... >>>>> 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 ... >>>>> 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 >> >> > > -- > 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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
