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

draft-ietf-tls-rfc8446bis.md

@@ -572,6 +572,10 @@ specific technical changes:
   is possible to send no extensions, which results in
   length 0.
 
+- Used more generic language for the asymmetric key exchange,
+  which was previously exclusively (EC)DHE,
+  to reflect the use of KEM-based key exchange.
+
 In addition, there have been some improvements to the
 security considerations, especially around privacy.
 
@@ -673,11 +677,15 @@ termination of the connection, optionally preceded by an alert message
 
 TLS supports three basic key exchange modes:
 
-- (EC)DHE (Diffie-Hellman over either finite fields or elliptic curves)
+- asymmetric key exchange
+
+- PSK
 
-- PSK-only
+- combined PSK and asymmetric key exchange
 
-- PSK with (EC)DHE
+In this document, asymmetric key exchange includes Diffie-Hellman
+over either finite fields or elliptic curves.
+Other extensions define the use of key-encapsulation mechanisms (KEMs).
 
 {{tls-full}} below shows the basic full TLS handshake:
 
@@ -743,14 +751,14 @@ The server processes the ClientHello and determines the appropriate
 cryptographic parameters for the connection. It then responds with its
 own ServerHello ({{server-hello}}), which indicates the negotiated connection
 parameters. The combination of the ClientHello
-and the ServerHello determines the shared keys. If (EC)DHE
+and the ServerHello determines the shared keys. If asymmetric
 key establishment is in use, then the ServerHello
 contains a "key_share" extension with the server's ephemeral
 Diffie-Hellman share; the server's share MUST be in the same group as one of the
 client's shares. If PSK key establishment is
 in use, then the ServerHello contains a "pre_shared_key"
 extension indicating which of the client's offered PSKs was selected.
-Note that implementations can use (EC)DHE and PSK together, in which
+Note that implementations can use asymmetric key exchange and PSK together, in which
 case both extensions will be supplied.
 
 The server then sends two messages to establish the Server Parameters:
@@ -867,7 +875,7 @@ instead of a full handshake.
 In TLS 1.2 and below, this functionality was provided by "session IDs" and
 "session tickets" {{RFC5077}}. Both mechanisms are obsoleted in TLS 1.3.
 
-PSKs can be used with (EC)DHE key exchange to provide forward
+PSKs can be used with asymmetric key exchange to provide forward
 secrecy in combination with shared keys, or can be used alone, at the
 cost of losing forward secrecy for the application data.
 
@@ -917,7 +925,7 @@ via a PSK, it SHOULD also supply a "key_share" extension to the server to
 allow the server to decline resumption and fall back
 to a full handshake, if needed. The server responds with a "pre_shared_key"
 extension to negotiate the use of PSK key establishment and can (as shown here)
-respond with a "key_share" extension to do (EC)DHE key establishment, thus
+respond with a "key_share" extension to do asymmetric key establishment, thus
 providing forward secrecy.
 
 When PSKs are provisioned externally, the PSK identity and the KDF hash
@@ -1304,9 +1312,9 @@ following four sets of options in its ClientHello:
 
 - A list of cipher suites which indicates the AEAD algorithm/HKDF hash
   pairs which the client supports.
-- A "supported_groups" ({{supported-groups}}) extension which indicates the (EC)DHE groups
+- A "supported_groups" ({{supported-groups}}) extension which indicates the key exchange groups
   which the client supports and a "key_share" ({{key-share}}) extension which contains
-  (EC)DHE shares for some or all of these groups.
+  key exchange shares for some or all of these groups.
 - A "signature_algorithms" ({{signature-algorithms}}) extension which indicates the signature
   algorithms which the client can accept. A "signature_algorithms_cert" extension ({{signature-algorithms}}) may also be
   added to indicate certificate-specific signature algorithms.
@@ -1318,20 +1326,20 @@ following four sets of options in its ClientHello:
 
 If the server does not select a PSK, then the first three of these
 options are entirely orthogonal: the server independently selects a
-cipher suite, an (EC)DHE group and key share for key establishment,
+cipher suite, an asymmetric key exchange group and key share for key establishment,
 and a signature algorithm/certificate pair to authenticate itself to
 the client. If there is no overlap between the received "supported_groups"
 and the groups supported by the server, then the server MUST abort the
 handshake with a "handshake_failure" or an "insufficient_security" alert.
 
 If the server selects a PSK, then it MUST also select a key
 establishment mode from the list indicated by the client's
-"psk_key_exchange_modes" extension (at present, PSK alone or with (EC)DHE). Note
-that if the PSK can be used without (EC)DHE, then non-overlap in the
+"psk_key_exchange_modes" extension (at present, PSK alone or with asymmetric key exchange). Note
+that if the PSK can be used without asymmetric key exchange, then non-overlap in the
 "supported_groups" parameters need not be fatal, as it is in the
 non-PSK case discussed in the previous paragraph.
 
-If the server selects an (EC)DHE group and the client did not offer a
+If the server selects an asymmetric key exchange group and the client did not offer a
 compatible "key_share" extension in the initial ClientHello, the server MUST
 respond with a HelloRetryRequest ({{hello-retry-request}}) message.
 
@@ -1342,8 +1350,8 @@ follows:
 - If PSK is being used, then the server will send a
   "pre_shared_key" extension indicating the selected key.
 
-- When (EC)DHE is in use, the server will also provide a "key_share"
-  extension. If PSK is not being used, then (EC)DHE and certificate-based
+- When asymmetric key exchange is in use, the server will also provide a "key_share"
+  extension. If PSK is not being used, then asymmetric key exchange and certificate-based
   authentication are always used.
 
 - When authenticating via a certificate, the server will send
@@ -1578,7 +1586,7 @@ extensions:
   the protocol version. All TLS 1.3 ServerHello messages MUST contain the
   "supported_versions" extension.  Current ServerHello messages additionally contain
   either the "pre_shared_key" extension or the "key_share" extension, or both (when using
-  a PSK with (EC)DHE key establishment). Other extensions
+  a PSK with asymmetric key establishment). Other extensions
   (see {{extensions}}) are sent
   separately in the EncryptedExtensions message.
 {:br }
@@ -2403,14 +2411,14 @@ server_share:
   client's shares.
 {:br}
 
-If using (EC)DHE key establishment, servers offer exactly one
+If using asymmetric key establishment, servers offer exactly one
 KeyShareEntry in the ServerHello. This value MUST be in the same group
 as the KeyShareEntry value offered
 by the client that the server has selected for the negotiated key exchange.
 Servers MUST NOT send a KeyShareEntry for any group not
 indicated in the client's "supported_groups" extension and
 MUST NOT send a KeyShareEntry when using the "psk_ke" PskKeyExchangeMode.
-If using (EC)DHE key establishment and a HelloRetryRequest containing a
+If using asymmetric key establishment and a HelloRetryRequest containing a
 "key_share" extension was received by the client, the client MUST verify that the
 selected NamedGroup in the ServerHello is the same as that in the HelloRetryRequest.
 If this check fails, the client MUST abort the handshake with an "illegal_parameter"
@@ -2508,7 +2516,7 @@ psk_ke:
 supply a "key_share" value.
 
 psk_dhe_ke:
-: PSK with (EC)DHE key establishment. In this mode,
+: PSK with asymmetric key establishment. In this mode,
 the client and server MUST supply "key_share" values as described
 in {{key-share}}.
 {:br}
@@ -4367,7 +4375,7 @@ input secrets are:
 
 - PSK (a pre-shared key established externally or derived from
   the resumption_secret value from a previous connection)
-- (EC)DHE shared secret ({{ecdhe-shared-secret-calculation}})
+- Asymmetric shared secret ({{ecdhe-shared-secret-calculation}})
 
 This produces the key schedule shown in the diagram below
 ({{key-schedule-diagram}}. In this diagram, the following formatting conventions apply:
@@ -4411,9 +4419,9 @@ from the handshake.
                  v
             Derive-Secret(., "derived", "")
                  |
-                 v
-  (EC)DHE --> HKDF-Extract = Handshake Secret
-                 |
+  asymmetric     v
+   shared --> HKDF-Extract = Handshake Secret
+   secret        |
                  +-----> Derive-Secret(., "c hs traffic",
                  |                     ClientHello...ServerHello)
                  |              = client_handshake_traffic_secret
@@ -4528,7 +4536,7 @@ underlying Secret changes (e.g., when changing from the handshake to
 Application Data keys or upon a key update).
 
 
-## (EC)DHE Shared Secret Calculation {#ecdhe-shared-secret-calculation}
+## Asymmetric Shared Secret Calculation {#ecdhe-shared-secret-calculation}
 
 ###  Finite Field Diffie-Hellman
 
@@ -4674,7 +4682,7 @@ and the corresponding PSKs are deleted upon use, then connections established
 using PSKs enjoy not only anti-replay protection, but also forward secrecy once
 all copies of the PSK from the database entry have been deleted.
 This mechanism also improves security for PSK usage when PSK is used without
-(EC)DHE.
+an asymmetric key exchange.
 
 Because this mechanism requires sharing the session database between
 server nodes in environments with multiple distributed servers,
@@ -5346,7 +5354,7 @@ TLS protocol issues:
   ClientHello?
 
 - As a server, do you send a HelloRetryRequest to clients which
-  support a compatible (EC)DHE group but do not predict it in the
+  support a compatible asymmetric key exchange group but do not predict it in the
   "key_share" extension? As a client, do you correctly handle a
   HelloRetryRequest from the server?
 
@@ -5694,7 +5702,7 @@ Downgrade Protection:
 Forward secret with respect to long-term keys:
 : If the long-term keying material (in this case the signature keys in
   certificate-based authentication modes or the external/resumption
-  PSK in PSK with (EC)DHE modes) is compromised after the handshake is
+  PSK in PSK with asymmetric key exchange modes) is compromised after the handshake is
   complete, this does not compromise the security of the session key
   (see {{?DOW92=DOI.10.1007/BF00124891}}), as long as the session key
   itself (and all material that could be used to recreate the session
@@ -5726,18 +5734,18 @@ Protection of endpoint identities:
 
 Informally, the signature-based modes of TLS 1.3 provide for the
 establishment of a unique, secret, shared key established by an
-(EC)DHE key exchange and authenticated by the server's signature over
+asymmetric key exchange and authenticated by the server's signature over
 the handshake transcript, as well as tied to the server's identity by
 a MAC. If the client is authenticated by a certificate, it also signs
 over the handshake transcript and provides a MAC tied to both
 identities. {{?SIGMA=DOI.10.1007/978-3-540-45146-4_24}} describes the design and analysis of this type of key
-exchange protocol. If fresh (EC)DHE keys are used for each connection,
+exchange protocol. If fresh asymmetric keys are used for each connection,
 then the output keys are forward secret.
 
 The external PSK and resumption PSK bootstrap from a long-term shared
 secret into a unique per-connection set of short-term session keys. This
 secret may have been established in a previous handshake. If
-PSK with (EC)DHE key establishment is used, these session keys will also be forward
+PSK with asymmetric key establishment is used, these session keys will also be forward
 secret. The resumption PSK has been designed so that the
 resumption secret computed by connection N and needed to form
 connection N+1 is separate from the traffic keys used by connection N,
@@ -5753,20 +5761,20 @@ Forward secrecy limits the effect of key leakage in one direction
 (compromise of a key at time T2 does not compromise some key at time
 T1 where T1 < T2). Protection in the other direction (compromise at
 time T1 does not compromise keys at time T2) can be achieved by
-rerunning (EC)DHE. If a long-term authentication key has been
-compromised, a full handshake with (EC)DHE gives protection against
+rerunning an asymmetric key exchange. If a long-term authentication key has been
+compromised, a full handshake with asymmetric key exchange gives protection against
 passive attackers. If the resumption_secret has been
-compromised, a resumption handshake with (EC)DHE gives protection
-against passive attackers and a full handshake with (EC)DHE gives
+compromised, a resumption handshake with asymmetric key exchange gives protection
+against passive attackers and a full handshake with asymmetric key exchange gives
 protection against active attackers. If a traffic secret has been
-compromised, any handshake with (EC)DHE gives protection against
+compromised, any handshake with asymmetric key exchange gives protection against
 active attackers. Using the terms in {{RFC7624}}, forward secrecy
-without rerunning (EC)DHE does not stop an attacker from doing static
+without rerunning asymmetric key exchange does not stop an attacker from doing static
 key exfiltration. After key exfiltration of
 application_traffic_secret_N, an attacker can e.g., passively
 eavesdrop on all future data sent on the connection including data
 encrypted with application_traffic_secret_N+1,
-application_traffic_secret_N+2, etc. Frequently rerunning (EC)DHE
+application_traffic_secret_N+2, etc. Frequently rerunning asymmetric key exchange
 forces an attacker to do dynamic key exfiltration (or content
 exfiltration).
 
@@ -5972,7 +5980,7 @@ provide post-compromise security/future secrecy/backward secrecy with respect
 to the traffic secret. Indeed, an attacker who learns a traffic secret can
 compute all future traffic secrets on that connection.  Systems which want such
 guarantees need to do a fresh handshake and establish a new connection with an
-(EC)DHE exchange.
+asymmetric key exchange.
 
 ### External References