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 retry_configs, 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 "illegal_parameter" alert in the case of "if
the field contains any other value", which apparently referred to
the retry_config version fields. First, this conflicts with the
requirement that the connection be aborted with ech_required.
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
illegal_parameter 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 "ech_retry_request". (See also
tlswg/draft-ietf-tls-esni#500).
…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 retry_configs, 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 "illegal_parameter" alert in the case of "if the field contains any other value", which apparently referred to the retry_config version fields. First, this conflicts with the requirement that the connection be aborted with ech_required. 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 illegal_parameter 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 "ech_retry_request". (See also tlswg/draft-ietf-tls-esni#500).