On Wed, Mar 13, 2024 at 6:39 PM Deirdre Connolly <durumcrustu...@gmail.com> wrote: > > Some considerations for ML-KEM alone (or another trusted PQ-only key > agreement) are mainly looking towards the desired next step after hybrid key > agreement, and instead of leaving that fuzzy and far off, talking about it in > the present. This is also motivated by -hybrid-design allowing several > traditional NamedGroups to be negotiated on their own, as hybrid NamedGroups > with ML-KEM (although currently both are specified as Kyber but those will > change), but no option to negotiate the other side of the hybrid alone, the > PQ algorithm alone, Shaking out all the negotiation decisions is desirable as > well as 'drawing the rest of the owl' for the pure PQ option implied in the > negotiation (are we going to copy the same ~1000 bytes for the PQ and hybrid > name groups, when sharing an ephemeral KEM keypair?).
Yes please. Otherwise we are going to face extreme pressure to support a cartesian product, and consequent API degeneration. To be clear i think each group should be independent. > > For CNSA 2.0, it is cited not as a compatibility _requirement_ of TLS, but a > note that a non-trivial segment of users of standard TLS that have been > traditionally compliant will not be in a few years, and they will come > knocking anyway. This is trying to skate where the puck is going. > > But also, the fact that CNSA 2.0 explicitly requires ML-KEM _only_ key > agreement in the next ~6-9 years is a strong vote of confidence in any > protocol doing this at all, so, TLS wouldn't be out on a limb to support > this, basically. > > I don't have a strong opinion on whether this should be Recommended = Y. I'm happy with letting the market decide: we can reevaluate later. Sincerely, Watson -- Astra mortemque praestare gradatim _______________________________________________ TLS mailing list TLS@ietf.org https://www.ietf.org/mailman/listinfo/tls
