[TLS] Re: Deprecate NIST curves in hybrid key exchanges?

[Loganaden Velvindron <[e-mail]>]

On Tue, 10 Jun 2025 at 12:30, Bellebaum, Thomas
<[e-mail]> wrote:
>
> 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?

I believe that a large government agency (nsa.gov) is using SecP256r1
on its website as a key exchange for TLS ?

 TLS 1.2 Cipher Suites:
     Attempted to connect using 156 cipher suites.

     The server accepted the following 3 cipher suites:
        TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256       256
ECDH: prime256v1 (256 bits)
        TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384             256
ECDH: prime256v1 (256 bits)
        TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256             128
ECDH: prime256v1 (256 bits)

I suspect that maybe other US government agencies might support
secp256r1 or prefer it for their own reasons.
Maybe the US agencies can publicly express themselves on this matter ?

Sometime ago, I made a proposal to have X25519 become a "MUST" for TLS
1.3 but that proposal failed to reach consensus.