On Tue, 10 Jun 2025 at 12:30, Bellebaum, Thomas
<[email protected]> 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.
_______________________________________________
TLS mailing list -- [email protected]
To unsubscribe send an email to [email protected]
