Draft: draft-ietf-tls-esni

Commentary: Handling server response discusses how to dispatch between accept / reject , but the retry flow is specifically the reject bit .
Paragraph (version A):
The DNS name of the client-facing server, i.e., the entity trusted
to update the ECH configuration.  This is used to correct
misconfigured clients, as described in handle-server-response.
Paragraph (version B):
The DNS name of the client-facing server, i.e., the entity trusted
to update the ECH configuration.  This is used to correct
misconfigured clients, as described in rejected-ech.
Paragraph (version A):
Note that authenticating a connection for the public name does not
authenticate it for the origin.  The TLS implementation MUST NOT
report such connections as successful to the application.  It
additionally MUST ignore all session tickets and session IDs
presented by the server.  These connections are only used to trigger
retries, as described in handle-server-response.  This may be
implemented, for instance, by reporting a failed connection with a
dedicated error code.
Paragraph (version B):
Note that authenticating a connection for the public name does not
authenticate it for the origin.  The TLS implementation MUST NOT
report such connections as successful to the application.  It
additionally MUST ignore all session tickets and session IDs
presented by the server.  These connections are only used to trigger
retries, as described in rejected-ech.  This may be implemented, for
instance, by reporting a failed connection with a dedicated error
code.
Paragraph (version A):
The retry mechanism repairs inconsistencies, provided the server is
authoritative for the public name.  If server and advertised keys
mismatch, the server will respond with ech_retry_requested.  If the
server does not understand the "encrypted_client_hello" extension at
all, it will ignore it as required by Section 4.1.2 of RFC8446.
Provided the server can present a certificate valid for the public
name, the client can safely retry with updated settings, as described
in handle-server-response.
Paragraph (version B):
The retry mechanism repairs inconsistencies, provided the server is
authoritative for the public name.  If server and advertised keys
mismatch, the server will respond with ech_retry_requested.  If the
server does not understand the "encrypted_client_hello" extension at
all, it will ignore it as required by Section 4.1.2 of RFC8446.
Provided the server can present a certificate valid for the public
name, the client can safely retry with updated settings, as described
in rejected-ech.
Paragraph (version A):
Depending on whether the client is configured to accept the proxy's
certificate as authoritative for the public name, this may trigger
the retry logic described in handle-server-response or result in a
connection failure.  A proxy which is not authoritative for the
public name cannot forge a signal to disable ECH.
Paragraph (version B):
Depending on whether the client is configured to accept the proxy's
certificate as authoritative for the public name, this may trigger
the retry logic described in rejected-ech or result in a connection
failure.  A proxy which is not authoritative for the public name
cannot forge a signal to disable ECH.