-
Notifications
You must be signed in to change notification settings - Fork 731
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Align on using the "group" over "curve" for ECDH in TLS
We're this awkward mix of "group" and "curve" right now. On the spec side, this is because they used to be "curves", but then RFC 7919 renamed to "group" in an attempt to generalize FFDH and ECDH. The negotiated FFDH stuff never really went anywhere (the way it used cipher suite values in TLS 1.2 made it unusable), but the name change stuck. In our implementation and API, we originally called it "curve". In preparation for TLS 1.3, we renamed the internals to "group" to match the spec in https://boringssl-review.googlesource.com/c/boringssl/+/7955, but the public API was still "curve". Then we exported a few more things in https://boringssl-review.googlesource.com/c/boringssl/+/8565, but I left it at "curve" to keep the public API self-consistent. Then we added OpenSSL's new "group" APIs in https://boringssl-review.googlesource.com/c/boringssl/+/54306, but didn't go as far to deprecate the old ones yet. Now I'd like to add new APIs to clear up the weird mix of TLS codepoints and NIDs that appear in our APIs. But our naming is a mess, so either choice of "group" or "curve" for the new API looks weird. In hindsight, we probably should have left it at "curve". Both terms are equally useless for the future post-quantum KEMs, but at least "curve" is more unique of a name than "group". But at this point, I think we're too far through the "group" rename to really backtrack: - Chromium says "group" in its internals - QUICHE says "group" in its internals and public API - Our internals say "group" - OpenSSL has switched to "group" and deprecated "curve", so new APIs will be based on "group" So align with all this and say "group". This CL handles set1_curves and set1_curves_list APIs, which already have "group" replacements from OpenSSL. A follow-up CL will handle our APIs. This is a soft deprecation because I don't think updating things is particularly worth the churn, but get the old names out of the way, so new code can have a simpler API to target. Also rewrite the documentation for that section accordingly. I don't think we need to talk about how it's always enabled now. That's a reference to some very, very old OpenSSL behavior where ECDH negotiation needed to be separately enabled. Change-Id: I7a356793d36419fc668364c912ca7b4f5c6c23a2 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/60206 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Adam Langley <agl@google.com> Reviewed-by: Bob Beck <bbe@google.com>
- Loading branch information
Showing
7 changed files
with
137 additions
and
160 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.