Re: [TLS] ML-KEM key agreement for TLS 1.3

[Watson Ladd <[e-mail]>]

On Wed, Mar 13, 2024 at 6:39 PM Deirdre Connolly
<[e-mail]> 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