Original text:
disabled by the server.  It SHOULD retry the handshake with a new transport connection and ECH disabled. <del> [[TODO: Key replacement is significantly less scary than saying that ECH-naive servers bounce ECH off.  Is it worth defining a strict mode toggle in the ECH keys, for a deployment to indicate it is ready for that? ]] </del> Clients SHOULD implement a limit on retries caused by "ech_retry_request" or servers which do not acknowledge the "encrypted_client_hello" extension.  If the client does not retry in 10.6. <del> Note that the backend server has no way of knowing what the SNI was, but that does not lead to additional privacy exposure because the backend server also only has one identity.  This does, however, change the situation slightly in that the backend server might previously have checked SNI and now cannot (and an attacker can route a connection with an encrypted SNI to any backend server and the TLS connection will still complete).  However, the client is still responsible for verifying the server's identity in its certificate. [[TODO: Some more analysis needed in this case, as it is a little odd, and probably some precise rules about handling ECH and no SNI uniformly?]] 10.7. </del> 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.8. </del>  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.8.1. </del>  This attack uses the client's reaction to an incorrect certificate as an oracle.  The attacker intercepts a legitimate ClientHello and needed for encrypting the Certificate message.  Thus, the client will fail to decrypt the Certificate and abort the connection. <del> 10.8.2. </del>  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.8.3. </del>  This attack uses resumption PSKs as an oracle for dictionary attacks against a given ClientHello's true SNI.  To begin, the attacker first

Reviewer comments:
The misrouting content no longer applies since the backend server sees the full CH, with the true SNI.

Revised text:
disabled by the server.  It SHOULD retry the handshake with a new transport connection and ECH disabled.  Clients SHOULD implement a limit on retries caused by "ech_retry_request" or servers which do not acknowledge the "encrypted_client_hello" extension.  If the client does not retry in 10.6.  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.  <ins> 10.7. </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.  <ins> 10.7.1. </ins> This attack uses the client's reaction to an incorrect certificate as an oracle.  The attacker intercepts a legitimate ClientHello and needed for encrypting the Certificate message.  Thus, the client will fail to decrypt the Certificate and abort the connection.  <ins> 10.7.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.  <ins> 10.7.3. </ins> This attack uses resumption PSKs as an oracle for dictionary attacks against a given ClientHello's true SNI.  To begin, the attacker first