Draft: draft-ietf-tls-esni

Commentary: See . 
 I left this out because I figure there may be cases where there is no " published " ECHConfigList . ( Maybe the config is baked in the app ? ) 
 Ah fair , that might be too precise . I think it still makes sense for that case to have the baked - in thing be an ECHConfigList than an ECHConfig , just for consistency . ( I 'm envisioning that ECHConfigList is the " public API " for client ECH and your TLS library might just that one byte string as input . ) How about s / published /  ? 
 That 'd work :) 
 done ! 
 LGTMThanks ,  !
Paragraph (version A):
The "ECHConfigs" structure contains one or more "ECHConfig"
structures in decreasing order of preference.  This allows a server
to support multiple versions of ECH and multiple sets of ECH
parameters.
Paragraph (version B):
The "ECHConfigList" structure contains one or more "ECHConfig"
structures in decreasing order of preference.  This allows a server
to support multiple versions of ECH and multiple sets of ECH
parameters.
Paragraph (version A):
An ECHConfigs structure containing one or more ECHConfig
structures, in decreasing order of preference, to be used by the
client in subsequent connection attempts.  These are known as the
server's "retry configurations".
Paragraph (version B):
An ECHConfigList structure containing one or more ECHConfig
structures, in decreasing order of preference, to be used by the
client in subsequent connection attempts.  These are known as the
server's "retry configurations".
Paragraph (version A):
To offer ECH, the client first chooses a suitable ECH configuration.
To determine if a given "ECHConfig" is suitable, it checks that it
supports the KEM algorithm identified by "ECHConfig.contents.kem_id",
at least one KDF/AEAD algorithm identified by
"ECHConfig.contents.cipher_suites", and the version of ECH indicated
by "ECHConfig.contents.version".  Once a suitable configuration is
found, the client selects the cipher suite it will use for
encryption.  It MUST NOT choose a cipher suite or version not
advertised by the configuration.  If no compatible configuration is
found, then the client SHOULD proceed as described in grease-ech.
Paragraph (version B):
To offer ECH, the client first chooses a suitable ECHConfig from the
server's ECHConfigList.  To determine if a given "ECHConfig" is
suitable, it checks that it supports the KEM algorithm identified by
"ECHConfig.contents.kem_id", at least one KDF/AEAD algorithm
identified by "ECHConfig.contents.cipher_suites", and the version of
ECH indicated by "ECHConfig.contents.version".  Once a suitable
configuration is found, the client selects the cipher suite it will
use for encryption.  It MUST NOT choose a cipher suite or version not
advertised by the configuration.  If no compatible configuration is
found, then the client SHOULD proceed as described in grease-ech.
Paragraph (version A):
Compare ClientECH.config_id against identifiers of known
ECHConfigs and select the ones that match, if any, as candidates.
Paragraph (version A):
Collect all known ECHConfigs as candidates, with trial decryption
below determining the final selection.
Paragraph (version B):
Compare ClientECH.config_id against identifiers of each known
ECHConfig and select the ones that match, if any, as candidates.
Paragraph (version B):
Collect all known ECHConfig values as candidates, with trial
decryption below determining the final selection.
Paragraph (version A):
ClientHelloOuterAAD is computed from ClientHelloOuter as described in
authenticating-outer.  The "info" parameter to SetupBaseS is the
concatenation "tls ech", a zero byte, and the serialized ECHConfig.
If decryption fails, the server continues to the next candidate
ECHConfig.  Otherwise, the server reconstructs ClientHelloInner from
EncodedClientHelloInner, as described in encoding-inner.  It then
stops considering candidate ECHConfigs.
Paragraph (version B):
ClientHelloOuterAAD is computed from ClientHelloOuter as described in
authenticating-outer.  The "info" parameter to SetupBaseS is the
concatenation "tls ech", a zero byte, and the serialized ECHConfig.
If decryption fails, the server continues to the next candidate
ECHConfig.  Otherwise, the server reconstructs ClientHelloInner from
EncodedClientHelloInner, as described in encoding-inner.  It then
stops iterating over the candidate ECHConfig values.
Paragraph (version A):
Otherwise, if all candidate ECHConfigs fail to decrypt the extension,
the client-facing server MUST ignore the extension and proceed with
the connection using ClientHelloOuter.  This connection proceeds as
usual, except the server MUST include the "encrypted_client_hello"
extension in its EncryptedExtensions with the "retry_configs" field
set to one or more ECHConfig structures with up-to-date keys.
Servers MAY supply multiple ECHConfig values of different versions.
This allows a server to support multiple versions at once.
Paragraph (version B):
Otherwise, if all candidate ECHConfig values fail to decrypt the
extension, the client-facing server MUST ignore the extension and
proceed with the connection using ClientHelloOuter.  This connection
proceeds as usual, except the server MUST include the
"encrypted_client_hello" extension in its EncryptedExtensions with
the "retry_configs" field set to one or more ECHConfig structures
with up-to-date keys.  Servers MAY supply multiple ECHConfig values
of different versions.  This allows a server to support multiple
versions at once.
Paragraph (version A):
Authenticating the ECHConfigs structure naturally authenticates the
included public name.  This also authenticates any retry signals from
the client-facing server because the client validates the server
certificate against the public name before retrying.
Paragraph (version B):
Authenticating the ECHConfig structure naturally authenticates the
included public name.  This also authenticates any retry signals from
the client-facing server because the client validates the server
certificate against the public name before retrying.