doc: remove statement about (EC)DHE performance by tniessen · Pull Request #41528 · nodejs/node

@tniessen

@nodejs-github-bot added doc

Issues and PRs related to the documentations.

tls

Issues and PRs related to the tls subsystem.

labels

Jan 14, 2022

addaleax

benjamingr

tniessen added a commit that referenced this pull request

Jan 16, 2022
This statement is misleading in that it says "key generation is
expensive". ECDHE key generation (over the elliptic curves that are
commonly used for TLS) is insanely fast compared to most other types
of key generation.

This statement is irrelevant for TLS 1.3, which requires (EC)DHE.

Even if this statement is somewhat true for TLS 1.2, it does not
justify discouraging the use of (EC)DHE.

PR-URL: #41528
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

mawaregetsuka pushed a commit to mawaregetsuka/node that referenced this pull request

Jan 17, 2022
This statement is misleading in that it says "key generation is
expensive". ECDHE key generation (over the elliptic curves that are
commonly used for TLS) is insanely fast compared to most other types
of key generation.

This statement is irrelevant for TLS 1.3, which requires (EC)DHE.

Even if this statement is somewhat true for TLS 1.2, it does not
justify discouraging the use of (EC)DHE.

PR-URL: nodejs#41528
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

thedull pushed a commit to thedull/node that referenced this pull request

Jan 18, 2022
This statement is misleading in that it says "key generation is
expensive". ECDHE key generation (over the elliptic curves that are
commonly used for TLS) is insanely fast compared to most other types
of key generation.

This statement is irrelevant for TLS 1.3, which requires (EC)DHE.

Even if this statement is somewhat true for TLS 1.2, it does not
justify discouraging the use of (EC)DHE.

PR-URL: nodejs#41528
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

BethGriggs pushed a commit that referenced this pull request

Jan 25, 2022
This statement is misleading in that it says "key generation is
expensive". ECDHE key generation (over the elliptic curves that are
commonly used for TLS) is insanely fast compared to most other types
of key generation.

This statement is irrelevant for TLS 1.3, which requires (EC)DHE.

Even if this statement is somewhat true for TLS 1.2, it does not
justify discouraging the use of (EC)DHE.

PR-URL: #41528
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

Linkgoron pushed a commit to Linkgoron/node that referenced this pull request

Jan 31, 2022
This statement is misleading in that it says "key generation is
expensive". ECDHE key generation (over the elliptic curves that are
commonly used for TLS) is insanely fast compared to most other types
of key generation.

This statement is irrelevant for TLS 1.3, which requires (EC)DHE.

Even if this statement is somewhat true for TLS 1.2, it does not
justify discouraging the use of (EC)DHE.

PR-URL: nodejs#41528
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>

danielleadams pushed a commit that referenced this pull request

Feb 26, 2022
This statement is misleading in that it says "key generation is
expensive". ECDHE key generation (over the elliptic curves that are
commonly used for TLS) is insanely fast compared to most other types
of key generation.

This statement is irrelevant for TLS 1.3, which requires (EC)DHE.

Even if this statement is somewhat true for TLS 1.2, it does not
justify discouraging the use of (EC)DHE.

PR-URL: #41528
Reviewed-By: Rich Trott <rtrott@gmail.com>
Reviewed-By: Anna Henningsen <anna@addaleax.net>
Reviewed-By: Benjamin Gruenbaum <benjamingr@gmail.com>