[TLS] Deprecate NIST curves in hybrid key exchanges?

["Bellebaum, Thomas" <[e-mail]>]

Hi everyone,

I have a question about draft-ietf-tls-ecdhe-mlkem. Some context:

ECDHE can be performed over any suitable elliptic curve, and different curves have different tradeoffs.
Focusing on KEX mentioned in RFC8446, Section 9, the (MUST support) P-256 provides benefits in terms of compliance with government regulations in the US, while the (much younger) curves in RFC 7748 are designed to circumvent some of the flaws discovered with P-256 deployments. It made sense to specify both of them, I think.

The picture is different when looking at ML-KEM (and other PQ) hybrids. If I understand correctly, FIPS-compliance only requires one of the KEX algorithms to be approved, so the draft states:

> All constructions aim to provide a FIPS-approved key-establishment scheme (as per [SP56C]).

At the same time there are regular concerns on this mailing list about the dangers of hybrids. Specifically, these usually relate to the amount of code in a TLS-enabled application, and possible security issues within these implementations.

This begs the question: Why are there several different curves used in the hybrids?
More specifically, given the low amount of code required to support ECDHE on X25519 [1], why would we require applications to implement other curves as well, long term?

The draft says about SecP256r1MLKEM768:

> The goal of this group is to support a use case that requires both shared secrets to be generated by FIPS-approved mechanisms.

Can someone please point me at the details of this use case, so that I can better understand the tradeoff?

Thanks to everyone in advance!

-- TBB

[1] Essentially the very easy field addition, multiplication, and inversion, and the montgomery ladder for the actual curve multiplication, plus some code for generating randomness and setting five bits, all of which are easily checked for correctness and at least memory safety.