Draft: draft-ietf-tls-esni

Commentary: A few editorial things that we missed before -08 .
Paragraph (version A):
ECH configuration extensions are used to to provide room for
additional functionality as needed.  See config-extensions-guidance
for guidance on which types of extensions are appropriate for this
structure.
Paragraph (version B):
ECH configuration extensions are used to provide room for additional
functionality as needed.  See config-extensions-guidance for guidance
on which types of extensions are appropriate for this structure.
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.kem_id" and at
least one KDF/AEAD algorithm identified by "ECHConfig.cipher_suites".
Once a suitable configuration is found, the client selects the cipher
suite it will use for encryption.  It MUST NOT choose a cipher suite
not advertised by the configuration.
Paragraph (version B):
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.kem_id", at least
one KDF/AEAD algorithm identified by "ECHConfig.cipher_suites", and
the version of ECH indicated by "ECHConfig.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.
Paragraph (version A):
If 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
that value to encrypt the ClientHello.  The value may only be applied
to the retry connection.  The client MUST continue to use the
previously-advertised keys for subsequent connections.  This avoids
introducing pinning concerns or a tracking vector, should a malicious
server present client-specific retry keys to identify clients.
Paragraph (version B):
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 continue to use the previously-advertised
configurations for subsequent connections.  This avoids introducing
pinning concerns or a tracking vector, should a malicious server
present client-specific retry keys to identify clients.
Paragraph (version A):
Set the "suite" field to a supported ECHCipherSuite.  The
selection SHOULD vary to exercise all supported configurations,
but MAY be held constant for successive connections to the same
server in the same session.
Paragraph (version B):
Set the "cipher_suite" field to a supported ECHCipherSuite.  The
selection SHOULD vary to exercise all supported configurations,
but MAY be held constant for successive connections to the same
server in the same session.
Paragraph (version A):
Set the "payload" field to a randomly-generated string of L+C
bytes, where C is the ciphertext expansion of selected AEAD scheme
and L is the size of the ClientHelloInner message the client would
use given an ECHConfig structure, padded according to padding.
Paragraph (version B):
Set the "payload" field to a randomly-generated string of L+C
bytes, where C is the ciphertext expansion of the selected AEAD
scheme and L is the size of the EncodedClientHelloInner the client
would compute when offering ECH, padded according to padding.
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 consider 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 considering candidate ECHConfigs.