"(EC)DHE" -> "asymmetric key exchange"

[martinthomson]

...or similar phrasing, throughout.

The use of (EC)DHE throughout really doesn't reflect actual usage any more, with the use now of KEMs for a lot of TLS usage (all, if things work out).

I know that DH is symmetric in a sense, but this seemed like the best phrasing to use. Happy to take suggestions for alternatives.

Looking at those KEM drafts, this would be helpful for them. Otherwise, they have to explain very carefully that their shared secret goes into the slot labeled "(EC)DHE" even though none of those letters applies to their thing.

[emanjon]

Good to remove (EC)DH fom the spec. "asymmetric key exchange" is a good modernization of (EC)DH but removes the important ending E which stands for ephemeral. The ephemeral part should not be removed.

"ephemeral asymmetric key exchange" would be a good replacement for (EC)DHE

[martinthomson]

While I agree with you, that would need to be a consensus position. I'm trying to stick within the painted lines.

(Apparently, we can't get consensus on the ephemeral thing and so we get specs with explicit provisions for key reuse instead.)

[emanjon]

I think removing an already existing "ephemeral" is a much smaller change than removing it, but I can live with "asymmetric key exchange".

Removing "ephemeral" in RFC 8446 is maybe even an improvement. The problem today is that static keys are common in visibility solutions, while RFC 8446 only talks about ephemeral keys and do not have any security considerations about static keys. I think it make sense to allow people to register key exchange with static keys, as long as they describe the security considerations.

[muhammad-usama-sardar]

I know that DH is symmetric in a sense, but this seemed like the best phrasing to use. Happy to take suggestions for alternatives.

I think there are two things here:

1. Process of key exchange
2. The resulting secret (namely g^xy)

While the process of key exchange is asymmetric, I believe (EC)DHE (namely g^xy) itself should be characterized as symmetric in the sense that both endpoints should end up with the same value. How about "shared ephemeral secret" instead of "asymmetric key exchange"?

---

Moreover, for such a change, I believe we not only need to check the security considerations carefully, but also add security considerations for KEMs.

---

Removing "ephemeral" in RFC 8446 is maybe even an improvement. The problem today is that static keys are common in visibility solutions, while RFC 8446 only talks about ephemeral keys and do not have any security considerations about static keys.

Unless I am misunderstanding something, from a formal analysis perspective, this seems to be a regression, rather than an improvement. All proofs to my knowledge are based on the assumption that g^x and g^y are freshly generated for each connection. Removing "ephemeral" will invalidate these proofs.

[ekr]

I think we should use "establishment" everywhere here.

[ekr]

I think removing an already existing "ephemeral" is a much smaller change than removing it, but I can live with "asymmetric key exchange".

Removing "ephemeral" in RFC 8446 is maybe even an improvement. The problem today is that static keys are common in visibility solutions, while RFC 8446 only talks about ephemeral keys and do not have any security considerations about static keys. I think it make sense to allow people to register key exchange with static keys, as long as they describe the security considerations.

Historically, in TLS, the distinction between static and ephemeral is whether the key is in a credential versus explicitly carried in the handshake (often signed by some key which is in a credential). That's what the E in DHE conveys, i.e., that it's potentially ephemeral, not that it's a one-time key [0]. This is of course a distinct question from whether key reuse is a good idea, whether it's allowed, etc, and TLS never took a position on how long you could reuse the keys. For example, you may recall that RFC 2246 contains an RSA_EXPORT mode in which the server supplied a temporary RSA key (explicitly described as "ephemeral RSA key" in RFC 2246), and these were often reused [1].

Now that we don't support static modes (in the sense above) at all, it's not clear to me how much the E is doing for us (and I don't think people say ML-KEME), so I favor keeping the text short, lest we have to mint a new acronym like "EAKE".

In agreement with Martin, I would be in favor of simply forbidding key reuse in TLS 1.3, but it seems we don't have WG consensus for that. However, I don't think whether the term "ephemeral" appears here changes things much one way or the other.

[0] Note that RFC 4949 defines ephemeral thus: "I) /adjective/ Refers to a cryptographic key or other cryptographic parameter or data object that is short-lived, temporary, or used one time. (See: session key. Compare: static.)"
[1] https://web.archive.org/web/20150304000214/http://blog.cryptographyengineering.com/2015/03/attack-of-week-freak-or-factoring-nsa.html "You see, it turns out that generating fresh RSA keys is a bit costly. So modern web servers don't do it for every single connection. In fact, Apache mod_ssl by default will generate a single export-grade RSA key when the server starts up, and will simply re-use that key for the lifetime of that server."

[thomwiggers]

Seems like a great idea