Thanks for both of these replies.... I'm (obviously) happy with the answers. I (also obviously) need more coffee/time before tackling these sorts of drafts.
Deb On Wed, Feb 4, 2026 at 8:41 PM Viktor Dukhovni <[email protected]> wrote: > On Thu, Feb 05, 2026 at 12:50:09AM +0000, Kris Kwiatkowski wrote: > > > > Section 5, FIPS compliance: Does the order that the shared secrets are > > > combined matter? > > > > Yes, the order of shares is swapped for X25519 and NIST curves, due to > > FIPS compliance. > > The presentation I've done at IETF 121 provides more details. > > - Video: > https://youtu.be/46ItvWI_k4Y?list=PLC86T-6ZTP5iW_EW2fpjMvIhLb1uTEkMQ&t=7000 > > - Slides: > https://datatracker.ietf.org/meeting/121/materials/slides-121-tls-post-quantum-hybrid-ecdhe-mlkem-key-agreement-for-tlsv13-00.pdf > > > > As a side note - we know that NIST is planning to allow custom order > > (it was confirmed by NIST). But at the time of writing, this is not > > finalized yet. > > FWIW, this order is in active use by multiple implementations. For > example, OpenSSL versions 3.5 (April 2025) and later place the ML-KEM > component of the hybrid keyshare first for the "ECX" hybrids > X25519MLKEM768 and X448MLKEM1024, and second for the ECDSA hybrids > SecP256r1MLKEM768 and SecP384r1MLKEM1024. > > [ There isn't yet a corresponding TLS codepoint for "X448MLKEM1024", > so that hybrid is for now dormant. ] > > And there is now a related IANA registration of an SM2 + ML-KEM hybrid, > in which the SM2 component is ordered first (perhaps by analogy with the > ECDSA cases in this draft): > > > https://datatracker.ietf.org/doc/html/draft-yang-tls-hybrid-sm2-mlkem-03#name-iana-considerations > > -- > Viktor. 🇺🇦 Слава Україні! > > _______________________________________________ > TLS mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ TLS mailing list -- [email protected] To unsubscribe send an email to [email protected]
