Support ECC curve other than 256-bit curve in gRPC SSL transport security

[jiangtaoli2016]

Right now, SSL transport security in gRPC only support 256-bit curve (hardcoded). See code. We shall revise to support more curves.

[stale]

This issue/PR has been automatically marked as stale because it has not had any update (including commits, comments, labels, milestones, etc) for 30 days. It will be closed automatically if no further update occurs in 7 day. Thank you for your contributions!

[danielywong]

Jiangtao and Mark, any update on this?

[jiangtaoli2016]

Daniel, do you have a use case?

[jiangtaoli2016]

@ZhenLian FYI

[danielywong]

We do have a potential use case. An ETA will be much appreciated. Thank you!

[danielywong]

use case of ed25519

[ZhenLian]

Foremost, the link in the original issue seems out of date. This should point to

{
    EC_KEY* ecdh = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
    if (!SSL_CTX_set_tmp_ecdh(context, ecdh)) {
      gpr_log(GPR_ERROR, "Could not set ephemeral ECDH key.");
      EC_KEY_free(ecdh);
      return TSI_INTERNAL_ERROR;
    }
    SSL_CTX_set_options(context, SSL_OP_SINGLE_ECDH_USE);
    EC_KEY_free(ecdh);
}

in ssl_transport_security.cc.

It has been discussed more frequently about the key algorithms used in gRPC these days, so I spent some time to read the code/articles talking about this. Let me quickly summarize what I have found so far:

1. it seems what is hardcoded is actually the DH parameter used when doing the ECDH key exchange. We could consider supporting more curves, or even more key exchange algorithms(e.g. PSK, as in TLS-PSK #24238), either by using an environmental variable(like how cipher suites are configured nowadays), or through a programatic parameter
2. the feature @danielywong wants, as I have learned, is to support loading more public key algorithms on the certificates. This is the algorithm we use to generate key-cert pairs, and it is not clear to me whether gRPC supports that. The point is, this problem is different from the original issue we wanted to track here. We did receive some feedback from @tavishvaidya saying gRPC couldn't load ECDSA P384 private key though. It probably has something to do with the key loading in OpenSSL/BoringSSL, but not the above code snippet happening during key exchange.