The server takes one of the following actions:¶
If it does not support ECH or cannot decrypt the extension, it completes +the handshake with ClientHelloOuter. This is referred to as rejecting ECH.¶
If it successfully decrypts the extension, it forwards the ClientHelloInner to the backend server, which completes the handshake. This is referred to -as accepting ECH.¶ +as accepting ECH.¶
Upon receiving the server's response, the client determines whether or not ECH @@ -1946,14 +1926,18 @@
Any referenced extension is missing in ClientHelloOuter.¶
Any extension is referenced in OuterExtensions more than once.¶
"encrypted_client_hello" is referenced in OuterExtensions.¶
The extensions in ClientHelloOuter corresponding to those in OuterExtensions +do not occur in the same order.¶
These requirements prevent an attacker from performing a packet amplification @@ -2024,19 +2008,23 @@
Next, the client constructs the ClientHelloInner message just as it does a standard ClientHello, with the exception of the following rules:¶
It MUST NOT offer to negotiate TLS 1.2 or below. This is necessary to ensure the backend server does not negotiate a TLS version that is incompatible with -ECH.¶ +ECH.¶
It MUST NOT offer to resume any session for TLS 1.2 and below.¶
If it intends to compress any extensions (see Section 5.1), it MUST +order those extensions consecutively.¶
inner as
+ It MUST include the "encrypted_client_hello" extension of type inner as
described in Section 5. (This requirement is not applicable
when the "encrypted_client_hello" extension is generated as described in
-Section 6.2.)¶
+Section 6.2.)¶
The client then constructs EncodedClientHelloInner as described in @@ -2052,36 +2040,43 @@
Next, it constructs a partial ClientHelloOuterAAD as it does a standard ClientHello, with the exception of the following rules:¶
It MUST offer to negotiate TLS 1.3 or above.¶
If it compressed any extensions in EncodedClientHelloInner, it MUST copy the corresponding extensions from ClientHelloInner. The copied extensions -additionally MUST be in the same relative order as in ClientHelloInner.¶ +additionally MUST be in the same relative order as in ClientHelloInner.¶
It MUST copy the legacy_session_id field from ClientHelloInner. This allows the server to echo the correct session ID for TLS 1.3's compatibility -mode (see Appendix D.4 of [RFC8446]) when ECH is negotiated.¶ +mode (see Appendix D.4 of [RFC8446]) when ECH is negotiated.¶
It MAY copy any other field from the ClientHelloInner except ClientHelloInner.random. Instead, It MUST generate a fresh ClientHelloOuter.random using a secure random number generator. (See -Section 10.11.1.)¶ +Section 10.11.1.)¶
ECHConfig.contents.public_name MUST be placed in the
-"server_name" extension.¶
+ The value of ECHConfig.contents.public_name MUST be placed in the
+"server_name" extension.¶
When the client offers the "pre_shared_key" extension in ClientHelloInner, it SHOULD also include a GREASE "pre_shared_key" extension in ClientHelloOuter, generated in the manner described in Section 6.1.2. The client MUST NOT use this extension to advertise a PSK to the client-facing server. (See Section 10.11.3.) When the client includes a GREASE "pre_shared_key" extension, it MUST also copy the "psk_key_exchange_modes" -from the ClientHelloInner into the ClientHelloOuter.¶ +from the ClientHelloInner into the ClientHelloOuter.¶
When the client offers the "early_data" extension in ClientHelloInner, it MUST also include the "early_data" extension in ClientHelloOuter. This allows servers that reject ECH and use ClientHelloOuter to safely ignore any -early data sent by the client per [RFC8446], Section 4.2.10.¶ +early data sent by the client per [RFC8446], Section 4.2.10.¶
Note that these rules may change in the presence of an application profile @@ -2109,16 +2104,16 @@
config_id, the identifier corresponding to the chosen ECHConfig structure;¶
+ config_id, the identifier corresponding to the chosen ECHConfig structure;¶
cipher_suite, the client's chosen cipher suite;¶
+ cipher_suite, the client's chosen cipher suite;¶
enc, as given above; and¶
+ enc, as given above; and¶
payload, a placeholder byte string containing L zeros.¶
+ payload, a placeholder byte string containing L zeros.¶
If configuration identifiers (see Section 10.4) are to be ignored, @@ -2189,20 +2184,24 @@
maximum_name_length field as follows, where L is the maximum_name_length
value.¶
If the ClientHelloInner contained a "server_name" extension with a name of +length D, add max(0, L - D) bytes of padding.¶
If the ClientHelloInner did not contain a "server_name" extension (e.g., if the client is connecting to an IP address), add L + 9 bytes of padding. This -is the length of a "server_name" extension with an L-byte name.¶ +is the length of a "server_name" extension with an L-byte name.¶
Finally, the client SHOULD pad the entire message as follows:¶
Let L be the length of the EncodedClientHelloInner with all the padding +computed so far.¶
Let N = 31 - ((L - 1) % 32) and add N bytes of padding.¶
This rounds the length of EncodedClientHelloInner up to a multiple of 32 bytes, @@ -2257,16 +2256,19 @@
If the server responds with a HelloRetryRequest, the client computes the updated ClientHello message as follows:¶
It computes a second ClientHelloInner based on the first ClientHelloInner, as in Section 4.1.4 of [RFC8446]. The ClientHelloInner's -"encrypted_client_hello" extension is left unmodified.¶ +"encrypted_client_hello" extension is left unmodified.¶
It constructs EncodedClientHelloInner as described in Section 5.1.¶
It constructs a second partial ClientHelloOuterAAD message. This message MUST be syntactically valid. The extensions MAY be copied from the original ClientHelloOuter unmodified, or omitted. If not sensitive, the client MAY -copy updated extensions from the second ClientHelloInner for compression.¶ +copy updated extensions from the second ClientHelloInner for compression.¶
It encrypts EncodedClientHelloInner as described in @@ -2334,12 +2336,14 @@
The client MUST verify that the certificate is valid for ECHConfig.contents.public_name. If invalid, it MUST abort the connection with -the appropriate alert.¶ +the appropriate alert.¶
If the server requests a client certificate, the client MUST respond with an +empty Certificate message, denoting no client certificate.¶
In verifying the client-facing server certificate, the client MUST interpret @@ -2367,20 +2371,24 @@
config_id field to a random byte.¶
+Set the config_id field to a random byte.¶
cipher_suite field to a supported HpkeSymmetricCipherSuite. The
+ Set the cipher_suite field to a supported HpkeSymmetricCipherSuite. The
selection SHOULD vary to exercise all supported configurations, but MAY be
held constant for successive connections to the same server in the same
-session.¶
+session.¶
enc field to a randomly-generated valid encapsulated public key
-output by the HPKE KEM.¶
+ Set the enc field to a randomly-generated valid encapsulated public key
+output by the HPKE KEM.¶
payload field to a randomly-generated string of L+C bytes, where C
+ Set the payload field to a randomly-generated string of L+C bytes, where C
is the ciphertext expansion of the selected AEAD scheme and L is the size of
the EncodedClientHelloInner the client would compute when offering ECH, padded
-according to Section 6.1.3.¶
+according to Section 6.1.3.¶
If sending a second ClientHello in response to a HelloRetryRequest, the @@ -2391,8 +2399,8 @@
If the server sends an "encrypted_client_hello" extension in either HelloRetryRequest or EncryptedExtensions, the client MUST check the extension syntactically and abort the connection with a "decode_error" alert if it is -invalid. It otherwise ignores the extension. It MUST NOT save the "retry_config" -value in EncryptedExtensions.¶
+invalid. It otherwise ignores the extension. It MUST NOT save the +"retry_configs" value in EncryptedExtensions.¶Offering a GREASE extension is not considered offering an encrypted ClientHello for purposes of requirements in Section 6.1. In particular, the client MAY offer to resume sessions established without ECH.¶
@@ -2408,15 +2416,18 @@Servers that support ECH play one of two roles, depending on the payload of the "encrypted_client_hello" extension in the initial ClientHello:¶
ECHClientHello.type is outer, then the server acts as a client-facing
+If ECHClientHello.type is outer, then the server acts as a client-facing
server and proceeds as described in Section 7.1 to extract a
-ClientHelloInner, if available.¶
+ClientHelloInner, if available.¶
ECHClientHello.type is inner, then the server acts as a backend server
-and proceeds as described in Section 7.2.¶
+ If ECHClientHello.type is inner, then the server acts as a backend server
+and proceeds as described in Section 7.2.¶
ECHClientHello.type is not a valid ECHClientHelloType, then
-the server MUST abort with an "illegal_parameter" alert.¶
+ Otherwise, if ECHClientHello.type is not a valid ECHClientHelloType, then
+the server MUST abort with an "illegal_parameter" alert.¶
If the "encrypted_client_hello" is not present, then the server completes the @@ -2434,11 +2445,13 @@
First, the server collects a set of candidate ECHConfig values. This list is determined by one of the two following methods:¶
Compare ECHClientHello.config_id against identifiers of each known ECHConfig +and select the ones that match, if any, as candidates.¶
Collect all known ECHConfig values as candidates, with trial decryption +below determining the final selection.¶
Some uses of ECH, such as local discovery mode, may randomize the @@ -2485,15 +2498,17 @@
If sending a HelloRetryRequest, the server MAY include an "encrypted_client_hello" extension with a payload of 8 random bytes; see -Section 10.9.4 for details.¶ +Section 10.9.4 for details.¶
If the server is configured with any ECHConfigs, it MUST include the "encrypted_client_hello" extension in its EncryptedExtensions with the "retry_configs" field set to one or more ECHConfig structures with up-to-date keys. Servers MAY supply multiple ECHConfig values of different versions. -This allows a server to support multiple versions at once.¶ +This allows a server to support multiple versions at once.¶
Note that decryption failure could indicate a GREASE ECH extension (see @@ -2683,11 +2698,14 @@
In the absence of an application profile standard specifying otherwise, a compliant ECH application MUST implement the following HPKE cipher suite:¶
KEM: DHKEM(X25519, HKDF-SHA256) (see Section 7.1 of [HPKE])¶
KDF: HKDF-SHA256 (see Section 7.2 of [HPKE])¶
AEAD: AES-128-GCM (see Section 7.3 of [HPKE])¶
Given these types of attackers, the primary goals of ECH are as follows.¶
Security preservation. Use of ECH does not weaken the security properties of +TLS without ECH.¶
Handshake privacy. TLS connection establishment to a host with a specific ECHConfig and TLS configuration is indistinguishable from a connection to any other host with the same ECHConfig and TLS configuration. (The set of hosts which share the same ECHConfig and TLS configuration is referred to -as the anonymity set.)¶ +as the anonymity set.)¶
Downgrade resistance. An attacker cannot downgrade a connection that +attempts to use ECH to one that does not use ECH.¶
These properties were formally proven in [ECH-Analysis].¶
@@ -2987,28 +3008,36 @@The attacker does not know the ECHConfigList used by the server.¶
The attacker keeps per-connection state only. In particular, it does not +track endpoints across connections.¶
ECH and GREASE ECH are designed so that the following features do not vary: the code points of extensions negotiated in the clear; the length of -messages; and the values of plaintext alert messages.¶ +messages; and the values of plaintext alert messages.¶
This leaves a variety of practical differentiators out-of-scope. including, though not limited to, the following:¶
the value of the configuration identifier;¶
the value of the outer SNI;¶
the TLS version negotiated, which may depend on ECH acceptance;¶
client authentication, which may depend on ECH acceptance; and¶
HRR issuance, which may depend on ECH acceptance.¶
These can be addressed with more sophisticated implementations, but some @@ -3259,19 +3288,21 @@
If looking up a ClientHelloOuter extension takes time linear in the number of extensions, the overall decoding process would take O(M*N) time, where M is the number of extensions in ClientHelloOuter and N is the -size of OuterExtensions.¶ +size of OuterExtensions.¶
If the same ClientHelloOuter extension can be copied multiple times, an attacker could cause the client-facing server to construct a large ClientHelloInner by including a large extension in ClientHelloOuter, of length L, and an OuterExtensions list referencing N copies of that extension. The client-facing server would then use O(N*L) memory in response to O(N+L) bandwidth from the client. In split-mode, an O(N*L) sized packet would then be transmitted to the -backend server.¶ +backend server.¶
ECH mitigates this attack by requiring that OuterExtensions be referenced in @@ -3297,11 +3328,13 @@
IANA is requested to create the following entries in the existing registry for ExtensionType (defined in [RFC8446]):¶
encrypted_client_hello(0xfe0d), with "TLS 1.3" column values set to +"CH, HRR, EE", and "Recommended" column set to "Yes".¶
ech_outer_extensions(0xfd00), with the "TLS 1.3" column values set to "", +and "Recommended" column set to "Yes".¶
Let I be zero and N be the number of extensions in ClientHelloOuter.¶
For each extension type, E, in OuterExtensions:¶
If E is "encrypted_client_hello", abort the connection with an +"illegal_parameter" alert and terminate this procedure.¶
While I is less than N and the I-th extension of +ClientHelloOuter does not have type E, increment I.¶
If I is equal to N, abort the connection with an "illegal_parameter" +alert and terminate this procedure.¶
Otherwise, the I-th extension of ClientHelloOuter has type E. Copy +it to the EncodedClientHelloInner and increment I.¶
Abort on duplicate OuterExtensions (#514)¶
Improve EncodedClientHelloInner definition (#503)¶
Clarify retry configuration usage (#498)¶
Expand on config_id generation implications (#491)¶
Server-side acceptance signal extension GREASE (#481)¶
Refactor overview, client implementation, and middlebox +sections (#480, #478, #475, #508)¶
Editorial iprovements (#485, #488, #490, #495, #496, #499, #500, +#501, #504, #505, #507, #510, #511)¶
Move ClientHello padding to the encoding (#443)¶
Align codepoints (#464)¶
Relax OuterExtensions checks for alignment with RFC8446 (#467)¶
Clarify HRR acceptance and rejection logic (#470)¶
Editorial improvements (#468, #465, #462, #461)¶
Make HRR confirmation and ECH acceptance explicit (#422, #423)¶
Relax computation of the acceptance signal (#420, #449)¶
Simplify ClientHelloOuterAAD generation (#438, #442)¶
Allow empty enc in ECHClientHello (#444)¶
Authenticate ECHClientHello extensions position in ClientHelloOuterAAD (#410)¶
Allow clients to send a dummy PSK and early_data in ClientHelloOuter when +applicable (#414, #415)¶
Compress ECHConfigContents (#409)¶
Validate ECHConfig.contents.public_name (#413, #456)¶
Validate ClientHelloInner contents (#411)¶
Note split-mode challenges for HRR (#418)¶
Editorial improvements (#428, #432, #439, #445, #458, #455)¶
Finalize HPKE dependency (#390)¶
Move from client-computed to server-chosen, one-byte config +identifier (#376, #381)¶
Rename ECHConfigs to ECHConfigList (#391)¶
Clarify some security and privacy properties (#385, #383)¶