Offer more EC curves by default for client connections

[yanavlasov]

By default Envoy offers only P-256 for EC curves on client connections. This creates hard to diagnose problem when a service offers curves with longer keys only. The error message has HANDSHAKE_FAILURE_ON_CLIENT_HELLO and you need to use TCP dump to figure out that there is mismatch between offered EC curves on client and server.

The suggestion is to include curves with higher keys by default for client connections.

"P-256","P-384","P-521" for FIPS and "P-256","P-384","P-521","X25519" for non-FIPS builds.

[yanavlasov]

@ggreenway

[ggreenway]

I think the current setting is due to the rational explained by @davidben here: #10855 (comment).

[paul-palmer]

I presume you mean rationale and not rational. Because the argument in #10855 is not rational. It implies that the dev's analysis of the risks of using P-384 outweigh the benefits in our environment (actually every environment everywhere) when they actually know almost nothing about the risks we are balancing in our environment. This lack of P-384 support is a real pain point for us.

I can understand the Envoy team setting defaults to what they consider to be generally best practice. Even so, they should leave room for users to adjust for their specific requirements. Please add a flag feature to enable the use of P-384 and add all of these warnings about its use in the documentation.

[yanavlasov]

The config option is already available: https://www.envoyproxy.io/docs/envoy/latest/api-v3/extensions/transport_sockets/tls/v3/common.proto#envoy-v3-api-msg-extensions-transport-sockets-tls-v3-tlsparameters

[github-actions]

This issue has been automatically marked as stale because it has not had activity in the last 30 days. It will be closed in the next 7 days unless it is tagged "help wanted" or "no stalebot" or other activity occurs. Thank you for your contributions.

[github-actions]

This issue has been automatically closed because it has not had activity in the last 37 days. If this issue is still valid, please ping a maintainer and ask them to label it as "help wanted" or "no stalebot". Thank you for your contributions.

[jdubs11]

Necro-ing these threads. NSA removed P256 from CNSA and now recommends P384 for EC curves. Does Envoy have plans to allow the use of P384?

[jdubs11]

@phlax can we get any traction here? I have a business need for Envoy to support P-384 curves.
Can I submit a PR?

[phlax]

Can I submit a PR?

go for it!

cc @ggreenway

[ggreenway]

@jdubs11 what are you specifically wanting supported? The original request in this issue is to change the default curves for client connections. However, additional curves have been supported for a long time if you configure them. And your comment suggests you're just wanting support for additional curves. Example:

--- a/examples/tls/envoy-http-https.yaml
+++ b/examples/tls/envoy-http-https.yaml
@@ -44,3 +44,10 @@ static_resources:
       name: envoy.transport_sockets.tls
       typed_config:
         "@type": type.googleapis.com/envoy.extensions.transport_sockets.tls.v3.UpstreamTlsContext
+        common_tls_context:
+          tls_params:
+            ecdh_curves:
+              - X25519
+              - P-256
+              - P-384
+              - P-521

[ggreenway]

The default in boringssl right now is {X25519, P-256, P-384}: https://boringssl.googlesource.com/boringssl/+/88d7a40bd06a34da6ee0d985545755199d047258/src/ssl/extensions.cc#311

[jdubs11]

@ggreenway yes I do want support for additional curves. Can I also specify P-384 for ECDSA curves? Basically I need Envoy to support P-384 curves for key exchange and authN using ECDSA certificates. In my current config, Envoy throws an error when I try to have it present an ECDSA cert generated on a P-384 curve.

Similarly if I start Envoy with an ECDSA cert generated on a P-256 curve, and then have a client using an ECDSA cert generated on P-384 curve try and connect using mTLS. Envoy throws an error about not supporting P-384. If I specify the curve as P-256 in the connection attempt just described, it does succeed. But P-384 is minimum for CNSA

[ggreenway]

Thanks for clarifying. There are a few different things in what you're asking for.

Can I also specify P-384 for ECDSA curves? Basically I need Envoy to support P-384 curves for key exchange and authN using ECDSA certificates.

These are two separate issues. For key exchange, this is already supported via configuration; it's just not the default. Changing that default is what this issue is requesting, but that shouldn't block you; you can configure ecdh_curves as needed for your setup.

For Envoy using a P-384 EC cert, either as a client or a server, that is what #10855 is requesting. Let's discuss that issue there.

Similarly if I start Envoy with an ECDSA cert generated on a P-256 curve, and then have a client using an ECDSA cert generated on P-384 curve try and connect using mTLS. Envoy throws an error about not supporting P-384. If I specify the curve as P-256 in the connection attempt just described, it does succeed. But P-384 is minimum for CNSA

Can you clarify what you mean by specify the curve as P-256 in the connection attempt? Do you mean specifying the ECDH curve? If that's the issue, I think that configuring Envoy's ecdh_curves to allow P-384 will fix this for you. I haven't tested this, but I'm pretty sure that Envoy will accept a P-384 ECDSA cert from a peer (in either a server or client context)