Change:
One of the motivations for encrypting HRR in was the leaks from cookie values. If we don't go with such a construction (which seems likely) and instead do or , cookies will be in the clear. That means it is instead on the backend servers to construct cookie values without leaking information. This PR provides security considerations to that effect. Unfortunately the requirements on backend servers within a Split Mode deployment are a bit onerous. I suspect, in practice, the answer is that Split Mode deployments cannot even use cookies on the backend server. Between HRRs being rare and stateless HRR being unnecessary over TCP or QUIC, that's hopefully fine. (Note this is different from , which was about the client-facing server being stateless. This applies if the backend server is stateless.)

Discussion:
10.7. <ins> Section 4.2.2 of RFC8446 defines a cookie value that servers may send in HelloRetryRequest for clients to echo in the second ClientHello. While ECH encrypts the cookie in the second ClientHelloInner, the backend server's HelloRetryRequest is unencrypted.This means differences in cookies between backend servers, such as lengths or cleartext components, may leak information about the server identity. Backend servers in an anonymity set SHOULD NOT reveal information in the cookie which identifies the server.  This may be done by handling HelloRetryRequest statefully, thus not sending cookies, or by using the same cookie construction for all backend servers. Note that, if the cookie includes a key name, analogous to Section 4 of RFC5077, this may leak information if different backend servers issue cookies with different key names at the time of the connection. In particular, if the deployment operates in Split Mode, the backend servers may not share cookie encryption keys.  Backend servers may mitigate this by either handling key rotation with trial decryption, or coordinating to match key names. 10.8. </ins> To signal acceptance, the backend server overwrites 8 bytes of its ServerHello.random with a value derived from the ClientHelloInner.random.  (See backend-server for details.)  This

Section 4.1.3).  These mechanisms do not interfere because the backend server only signals ECH acceptance in TLS 1.3 or higher. <del> 10.8. </del> <ins> 10.9. </ins> RFC8744 lists several requirements for SNI encryption.  In this section, we re-iterate these requirements and assess the ECH design against them. <del> 10.8.1. </del> <ins> 10.9.1. </ins> Since servers process either ClientHelloInner or ClientHelloOuter, and because ClientHelloInner.random is encrypted, it is not possible for an attacker to "cut and paste" the ECH value in a different Client Hello and learn information from ClientHelloInner. <del> 10.8.2. </del> <ins> 10.9.2. </ins> This design depends upon DNS as a vehicle for semi-static public key distribution.  Server operators may partition their private keys

by publishing different DNS records containing ECHConfig values with different keys using a short TTL. <del> 10.8.3. </del> <ins> 10.9.3. </ins> This design requires servers to decrypt ClientHello messages with ClientECH extensions carrying valid digests.  Thus, it is possible

attack is bound by the number of valid TCP connections an attacker can open. <del> 10.8.4. </del> <ins> 10.9.4. </ins> As a means of reducing the impact of network ossification, RFC8744 recommends SNI-protection mechanisms be designed in such a way that

some mitigations require coordination between the client and server. These mitigations are out-of-scope for this specification. <del> 10.8.5. </del> <ins> 10.9.5. </ins> This design is not forward secret because the server's ECH key is static.  However, the window of exposure is bound by the key lifetime.  It is RECOMMENDED that servers rotate keys frequently. <del> 10.8.6. </del> <ins> 10.9.6. </ins> This design permits servers operating in Split Mode to forward connections directly to backend origin servers.  The client

the client-facing server because the client validates the server certificate against the public name before retrying. <del> 10.8.7. </del> <ins> 10.9.7. </ins> This design has no impact on application layer protocol negotiation. It may affect connection routing, server certificate selection, and

entire ClientHello, this design additionally supports encrypting the ALPN extension. <del> 10.9. </del> <ins> 10.10. </ins> Variations in the length of the ClientHelloInner ciphertext could leak information about the corresponding plaintext. padding describes a RECOMMENDED padding mechanism for clients aimed at reducing potential information leakage. <del> 10.10. </del> <ins> 10.11. </ins> This section describes the rationale for ECH properties and mechanics as defenses against active attacks.  In all the attacks below, the

of the attacker is to learn private information about the inner ClientHello, such as the true SNI value. <del> 10.10.1. </del> <ins> 10.11.1. </ins> This attack uses the client's reaction to an incorrect certificate as an oracle.  The attacker intercepts a legitimate ClientHello and

Certificate message.  Thus, the client will fail to decrypt the Certificate and abort the connection. <del> 10.10.2. </del> <ins> 10.11.2. </ins> This attack aims to exploit server HRR state management to recover information about a legitimate ClientHello using its own attacker-

for equality and changes behavior based on the result can be used as an oracle to learn the client's SNI. <del> 10.10.3. </del> <ins> 10.11.3. </ins> This attack aims to leak information about secret parts of the encrypted ClientHello by adding attacker-controlled parameters and