Draft: draft-ietf-tls-esni

Commentary: … eliminate redundancies Avoid restatement by relying on the itemization of conditions that constitute ECH rejection given in 6.1.4 . The prior text described aborting the connection with an alert , then processing retryconfigs , which processing could then lead to additional instructions to abort the ( aborted ) connection with an alert ( and possibly a different alert than at first ) . Remove the use of the " illegalparameter " alert in the case of " if the field contains any other value " , which apparently referred to the retryconfig version fields . First , this conflicts with the requirement that the connection be aborted with echrequired . Second , it 's not clear what " any other value " is supposed to mean as this determination follows determining whether the members of the set of values are either " supported " or " unsupported " . Perhaps it meant a value not considered valid as of the specification version the client was implemented according to ? Certainly , in the case where there is at least one supported version found but also at least one such invalid value , it would not be desriable to use an illegalparameter alert , as this situation will naturally arise when servers deploying a new ECH version alongside an existing one serve clients that have not yet been upgraded . It 's also unclear what value client discrimination of unsupported - recognized - as - valid from unsupported - not - recognized - as - valid provides . Linearize the presentation . Fix the reference to the obsolete " echretry_request " . ( See also tlswg / draft - ietf - tls - esni ) .
Paragraph (version A):
If the server rejects ECH, the client proceeds with the handshake,
authenticating for ECHConfig.contents.public_name as described in
auth-public-name.  If authentication or the handshake fails, the
client MUST return a failure to the calling application.  It MUST NOT
use the retry configurations.
Paragraph (version A):
Otherwise, if both authentication and the handshake complete
successfully, the client MUST abort the connection with an
"ech_required" alert.  It then processes the "retry_configs" field
from the server's "encrypted_client_hello" extension.
Paragraph (version A):
If at least one of the values contains a version supported by the
client, it can regard the ECH keys as securely replaced by the
server.  It SHOULD retry the handshake with a new transport
connection, using the retry configurations supplied by the server.
The retry configurations may only be applied to the retry connection.
The client MUST NOT use retry configurations for connections beyond
the retry.  This avoids introducing pinning concerns or a tracking
vector, should a malicious server present client-specific retry
configurations in order to identify the client in a subsequent ECH
handshake.
Paragraph (version A):
If none of the values provided in "retry_configs" contains a
supported version, the client can regard ECH as securely disabled by
the server.  As below, it SHOULD then retry the handshake with a new
transport connection and ECH disabled.
Paragraph (version A):
If the field contains any other value, the client MUST abort the
connection with an "illegal_parameter" alert.
Paragraph (version A):
If the server negotiates an earlier version of TLS, or if it does not
provide an "encrypted_client_hello" extension in EncryptedExtensions,
the client proceeds with the handshake, authenticating for
ECHConfig.contents.public_name as described in auth-public-name.  If
an earlier version was negotiated, the client MUST NOT enable the
False Start optimization RFC7918 for this handshake.  If
authentication or the handshake fails, the client MUST return a
failure to the calling application.  It MUST NOT treat this as a
secure signal to disable ECH.
Paragraph (version A):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"ech_required" alert.  The client can then regard ECH as securely
disabled by the server.  It SHOULD retry the handshake with a new
transport connection and ECH disabled.
Paragraph (version A):
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
either scenario, it MUST report an error to the calling application.
Paragraph (version B):
If the server rejects ECH, the client proceeds with the handshake,
authenticating for ECHConfig.contents.public_name as described in
auth-public-name.  If authentication or the handshake fails, the
client MUST return a failure to the calling application.  It MUST NOT
use the retry configurations.  It MUST NOT treat this as a secure
signal to disable ECH.
Paragraph (version B):
If the server supplied an "encrypted_client_hello" extension in its
EncryptedExtensions message, the client MUST check that it is
syntactically valid and the client MUST abort the connection with a
"decode_error" alert otherwise.  If an earlier TLS version was
negotiated, the client MUST NOT enable the False Start optimization
RFC7918 for this handshake.  If both authentication and the handshake
complete successfully, the client MUST perform the processing
described below then abort the connection with an "ech_required"
alert before sending any application data to the server.
Paragraph (version B):
If the server provided "retry_configs" and if at least one of the
values contains a version supported by the client, the client can
regard the ECH keys as securely replaced by the server.  It SHOULD
retry the handshake with a new transport connection, using the retry
configurations supplied by the server.  The retry configurations may
only be applied to the retry connection.  The client MUST NOT use
retry configurations for connections beyond the retry.  This avoids
introducing pinning concerns or a tracking vector, should a malicious
server present client-specific retry configurations in order to
identify the client in a subsequent ECH handshake.
Paragraph (version B):
If none of the values provided in "retry_configs" contains a
supported version, or an earlier TLS version was negotiated, the
client can regard ECH as securely disabled by the server, and it
SHOULD retry the handshake with a new transport connection and ECH
disabled.
Paragraph (version B):
Clients SHOULD implement a limit on retries caused by receipt of
"retry_configs" or servers which do not acknowledge the
"encrypted_client_hello" extension.  If the client does not retry in
either scenario, it MUST report an error to the calling application.