Support P-384 and P-521 Server ECDSA Certificates

[JoelHenn]

Title: Support P-384 and P-521 Server ECDSA Certificates

Description:
Update Envoy to support server ECDSA certificates P-384 and P-521. Given that BoringSSL supports these curves, Envoy should allow servers to use certs with those curves to terminate TLS. The expected behavior is for Envoy to take an ECDSA cert and check to make sure it uses one of the three approved curves.

Relevant Links
Older PR for rejecting non P-256 server ECDSA certs: #5224

[ggreenway]

cc @PiotrSikora @davidben

[davidben]

(Also @agl )

The P-256 restriction is to avoid misconfigurations, reduce DoS risks, and keep the ecosystem healthy. The leaf certificate key is used to perform an signature on every TLS connection. That means that both performance and side-channel resistance are important. Performance problems translate to DoS risks for the server, and side-channel problems translate to loss of private key. (Cloud providers are especially sensitive to the DoS risks as private keys are often supplied externally.)

Good EC implementations are tuned to the specific curve, requiring error-prone optimizations. This means the ecosystem-wide cost of new curves is high. The bulk of implementation effort is spent on P-256. This is a good thing as it reduces those costs. While BoringSSL does have P-384 and P-521 APIs, they currently use a generic fallback implementation.

Additionally, even with a tuned implementation, keep in mind that EC operations scale cubicly. That means there is a significant cost to chasing bigger numbers. For TLS ECDSA leaf keys, P-256 is the right answer. (Many clients don't even allow P-521 in TLS, including BoringSSL in its default client configuration.)

[james-mathiesen]

We have existing Java applications that expect P-384 client certificates and we hit this trying to make HTTPS calls through envoy (as configured by istio). We have RSA leaf certs available and are testing with those but the root and intermediates will still be P-384.

[stale]

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 other activity occurs. Thank you for your contributions.

[stale]

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". Thank you for your contributions.

[cretz]

Both nist/fips and browsers support P-384 and I personally would opt-in to it even with impl perf concerns. Is it reasonable to revive this conversation? Would opt-in be acceptable? Has anything changed from a BoringSSL perspective on P-384 support since a year ago?

[ggreenway]

I would be fine with the perf concerns, but I am concerned about the side-channel resistance.

[davidben]

BoringSSL's position has not changed from #10855 (comment). While we support P-384 and do aim for side channel resistance in our generic implementation, it is still the case that P-256 is a more important curve and gets far more attention. P-256 is the right answer for TLS ECDSA leaf keys.

[cretz]

The question becomes, should non-default, opt-in support for P-384 be allowed for the discerning admin that is aware of the tradeoffs? When I say opt-in, I don't mean if it happens to be on the cert, I mean a literal curve list that defaults to P-256 only but allows a list of P-256 + P-384 akin to what is done on the connection side at https://github.com/envoyproxy/envoy/blob/v1.17.1/api/envoy/extensions/transport_sockets/tls/v3/common.proto#L92-L107

[davidben]

I think you're confusing two different (but, in TLS 1.2, related due to the mixed negotiation) things. There's the ECDH curve in the key exchange, and the ECDSA curve in the leaf certificate.

For ECDH in TLS, X25519 is the right answer, but supporting P-256 is also fine for compatibility. Though note that, only supporting P-256 ECDH in TLS 1.3 servers will cost an extra round-trip against some clients, including Chrome, due to HelloRetryRequest.
For ECDSA in TLS leaf certificates, P-256 is the right answer.