Draft: draft-ietf-tls-esni

Commentary: While cutsy , the name " ECHO " for " Encrypted Client Hello " seems like it could cause problems and significant confusion . To those not actively involved in the working group , " ECHO " has very different connotations . Some potential risks include : Other IETF standards have some form of " ECHO " functionality . When bouncing this question off someone else , they responded with " TLS ECHO , like ICMP ECHO , except totally not " The immediate guess people may have on hearing about a TLS ECHO functionality would be to think " oh , like to echo back a message for heartbeat purposes ? " . Given the potential risk for confusion with heartbeat ( especially given " Heartbleed " ) this has some risk of giving TLS ECHO a bad rap from the start due to confusion . This functionality is going to have high profile with product managers and perhaps even government regulators and public policy . Applying a name that has confusing lay - connotations is going to muddle conversations . This has a risk of confusion when used in other contexts . For example , " echoconfig " as a SVCB parameter key has potential risk for confusing people reading the config and lacking context . ECHO is going to be harder to do searches for , both in Internet and intranet search engines . Just calling it " ECH " or " EHELLO " may be safer ? ( If this changes , SVCB will also need to change the " echoconfig " . ) 
 One reason for " EHELLO " is that if we support   with the ClientHelloInner being TLS 1.2 then it also provides protection for the ServerHello as well . 
 ETCH 
 ETCH = = " Encrypted TLS Client Hello " ? ( That also sounds like a fine option . )
Paragraph (version A):
This document defines a simple mechanism for encrypting the Server
Name Indication for TLS 1.3.
Paragraph (version B):
This document defines a mechanism for encrypting a TLS 1.3
ClientHello.
Paragraph (version A):
Cleartext client DNS queries.
Paragraph (version A):
Visible server IP addresses, assuming the the server is not doing
domain-based virtual hosting.
Paragraph (version A):
Cleartext Server Name Indication (SNI) RFC6066 in ClientHello
messages.
Paragraph (version A):
DoH I-D.ietf-doh-dns-over-https and DPRIVE RFC7858 RFC8094 provide
mechanisms for clients to conceal DNS lookups from network
inspection, and many TLS servers host multiple domains on the same IP
address.  In such environments, SNI is an explicit signal used to
determine the server's identity.  Indirect mechanisms such as traffic
analysis also exist.
Paragraph (version A):
The TLS WG has extensively studied the problem of protecting SNI, but
has been unable to develop a completely generic solution.  I-D.ietf-
tls-sni-encryption provides a description of the problem space and
some of the proposed techniques.  One of the more difficult problems
is "Do not stick out" (I-D.ietf-tls-sni-encryption, Section 3.4): if
only sensitive/private services use SNI encryption, then SNI
encryption is a signal that a client is going to such a service.  For
this reason, much recent work has focused on concealing the fact that
SNI is being protected.  Unfortunately, the result often has
undesirable performance consequences, incomplete coverage, or both.
Paragraph (version A):
The design in this document takes a different approach: it assumes
that private origins will co-locate with or hide behind a provider
(CDN, app server, etc.) which is able to activate encrypted SNI, by
encrypting the entire ClientHello (ECHO), for all of the domains it
hosts.  As a result, the use of ECHO to protect the SNI does not
indicate that the client is attempting to reach a private origin, but
only that it is going to a particular service provider, which the
observer could already tell from the IP address.
Paragraph (version B):
Although TLS 1.3 RFC8446 encrypts most of the handshake, including
the server certificate, there are several ways in which an on-path
attacker can learn private information about the connection.  The
cleartext Server Name Indication (SNI) extension in ClientHello
messages, which leaks the target domain for a given connection, is
perhaps the most sensitive information unencrypted in TLS 1.3.
Paragraph (version B):
The target domain may also be visible through other channels, such as
cleartext client DNS queries, visible server IP addresses (assuming
the server does not use domain-based virtual hosting), or other
indirect mechanisms such as traffic analysis.  DoH I-D.ietf-doh-dns-
over-https and DPRIVE RFC7858 RFC8094 provide mechanisms for clients
to conceal DNS lookups from network inspection, and many TLS servers
host multiple domains on the same IP address.  In such environments,
the SNI remains the primary explicit signal used to determine the
server's identity.
Paragraph (version B):
The TLS WG has extensively studied the problem of protecting the SNI,
but has been unable to develop a completely generic solution.  I-
D.ietf-tls-sni-encryption provides a description of the problem space
and some of the proposed techniques.  One of the more difficult
problems is "Do not stick out" (I-D.ietf-tls-sni-encryption,
Section 3.4): if only sensitive or private services use SNI
encryption, then SNI encryption is a signal that a client is going to
such a service.  For this reason, much recent work has focused on
concealing the fact that the SNI is being protected.  Unfortunately,
the result often has undesirable performance consequences, incomplete
coverage, or both.
Paragraph (version B):
The design in this document takes a different approach: it assumes
that private origins will co-locate with or hide behind a provider
(CDN, application server, etc.) which can protect SNIs for all of the
domains it hosts.  As a result, SNI protection does not indicate that
the client is attempting to reach a private origin, but only that it
is going to a particular service provider, which the observer could
already tell from the visible IP address.
Paragraph (version B):
The design in this document introduces a new extension, called
Encrypted Client Hello (ECH), which allows clients to encrypt the
entirety of their ClientHello to a supporting server.  This protects
the SNI and other potentially sensitive fields, such as the ALPN
list.
Paragraph (version A):
ECHO works by encrypting the entire ClientHello, including the SNI
and any additional extensions such as ALPN.  This requires that each
provider publish a public key and metadata which is used for
ClientHello encryption for all the domains for which it serves
directly or indirectly (via Split Mode).  This document defines the
format of the SNI encryption public key and metadata, referred to as
an ECHO configuration, and delegates DNS publication details to
HTTPSSVC, though other delivery mechanisms are possible.  In
particular, if some of the clients of a private server are
applications rather than Web browsers, those applications might have
the public key and metadata preconfigured.
Paragraph (version A):
When a client wants to form a TLS connection to any of the domains
served by an ECHO-supporting provider, it constructs a ClientHello in
the regular fashion containing the true SNI value (ClientHelloInner)
and then encrypts it using the public key for the provider.  It then
constructs a new ClientHello (ClientHelloOuter) with an innocuous SNI
(and potentially innocuous versions of other extensions such as ALPN
RFC7301) and containing the encrypted ClientHelloInner as an
extension.  It sends ClientHelloOuter to the server.
Paragraph (version B):
ECH works by encrypting the entire ClientHello, including the SNI and
any additional extensions such as ALPN.  This requires that each
provider publish a public key and metadata which is used for
ClientHello encryption for all the domains for which it serves
directly or indirectly (via Split Mode).  This document defines the
format of the SNI encryption public key and metadata, referred to as
an ECH configuration, and delegates DNS publication details to
HTTPSSVC, though other delivery mechanisms are possible.  In
particular, if some of the clients of a private server are
applications rather than Web browsers, those applications might have
the public key and metadata preconfigured.
Paragraph (version B):
When a client wants to form a TLS connection to any of the domains
served by an ECH-supporting provider, it constructs a ClientHello in
the regular fashion containing the true SNI value (ClientHelloInner)
and then encrypts it using the public key for the provider.  It then
constructs a new ClientHello (ClientHelloOuter) with an innocuous SNI
(and potentially innocuous versions of other extensions such as ALPN
RFC7301) and containing the encrypted ClientHelloInner as an
extension.  It sends ClientHelloOuter to the server.
Paragraph (version A):
ClientHello encryption configuration information is conveyed with the
following ECHOConfigs structure.
Paragraph (version A):
The ECHOConfigs structure contains one or more ECHOConfig structures
in decreasing order of preference.  This allows a server to support
multiple versions of ECHO and multiple sets of ECHO parameters.
Paragraph (version A):
The version of the structure.  For this specification, that value
SHALL be 0xff03.  Clients MUST ignore any ECHOConfig structure
with a version they do not understand.
Paragraph (version A):
An opaque byte string whose contents depend on the version of the
structure.  For this specification, the contents are an
ECHOConfigContents structure.
Paragraph (version B):
ClientHello encryption configuration information is conveyed with the
following ECHConfigs structure.
Paragraph (version B):
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 version of the structure.  For this specification, that value
SHALL be 0xff03.  Clients MUST ignore any ECHConfig structure with
a version they do not understand.
Paragraph (version B):
An opaque byte string whose contents depend on the version of the
structure.  For this specification, the contents are an
ECHConfigContents structure.
Paragraph (version A):
The HPKE I-D.irtf-cfrg-hpke KEM identifier corresponding to
public_key.  Clients MUST ignore any ECHOConfig structure with a
key using a KEM they do not support.
Paragraph (version B):
The HPKE I-D.irtf-cfrg-hpke KEM identifier corresponding to
public_key.  Clients MUST ignore any ECHConfig structure with a
key using a KEM they do not support.
Paragraph (version A):
The format is defined in RFC8446, Section 4.2.  The same
interpretation rules apply: extensions MAY appear in any order, but
there MUST NOT be more than one extension of the same type in the
extensions block.  An extension can be tagged as mandatory by using
an extension type codepoint with the high order bit set to 1.  A
client which receives a mandatory extension they do not understand
MUST reject the ECHOConfig content.
Paragraph (version A):
Clients MUST parse the extension list and check for unsupported
mandatory extensions.  If an unsupported mandatory extension is
present, clients MUST reject the ECHOConfig value.
Paragraph (version B):
The format is defined in RFC8446, Section 4.2.  The same
interpretation rules apply: extensions MAY appear in any order, but
there MUST NOT be more than one extension of the same type in the
extensions block.  An extension can be tagged as mandatory by using
an extension type codepoint with the high order bit set to 1.  A
client which receives a mandatory extension they do not understand
MUST reject the ECHConfig content.
Paragraph (version B):
Clients MUST parse the extension list and check for unsupported
mandatory extensions.  If an unsupported mandatory extension is
present, clients MUST reject the ECHConfig value.
Paragraph (version A):
The HpkeCipherSuite cipher suite used to encrypt ClientHelloInner.
This MUST match a value provided in the corresponding
ECHOConfig.cipher_suites list.
Paragraph (version A):
A cryptographic hash of the ECHOConfig structure from which the
ECHO key was obtained, i.e., from the first byte of "version" to
the end of the structure.  This hash is computed using the hash
function associated with "suite", i.e., the corresponding HPKE KDF
algorithm hash.
Paragraph (version B):
The HpkeCipherSuite cipher suite used to encrypt ClientHelloInner.
This MUST match a value provided in the corresponding
ECHConfig.cipher_suites list.
Paragraph (version B):
A cryptographic hash of the ECHConfig structure from which the ECH
key was obtained, i.e., from the first byte of "version" to the
end of the structure.  This hash is computed using the hash
function associated with "suite", i.e., the corresponding HPKE KDF
algorithm hash.
Paragraph (version A):
An ECHOConfigs structure containing one or more ECHOConfig
structures in decreasing order of preference that the client
should use on subsequent connections to encrypt the
ClientHelloInner structure.
Paragraph (version A):
This protocol also defines the "echo_required" alert, which is sent
by the client when it offered an "encrypted_client_hello" extension
which was not accepted by the server.
Paragraph (version A):
A 16-byte nonce exported from the HPKE encryption context.  See
send-echo for details about its computation.
Paragraph (version A):
Finally, requirements in client-behavior and server-behavior require
implementations to track, alongside each PSK established by a
previous connection, whether the connection negotiated this extension
with the "echo_accept" response type.  If so, this is referred to as
an "ECHO PSK".  Otherwise, it is a "non-ECHO PSK".  This may be
implemented by adding a new field to client and server session
states.
Paragraph (version B):
An ECHConfigs structure containing one or more ECHConfig
structures in decreasing order of preference that the client
should use on subsequent connections to encrypt the
ClientHelloInner structure.
Paragraph (version B):
This protocol also defines the "ech_required" alert, which is sent by
the client when it offered an "encrypted_client_hello" extension
which was not accepted by the server.
Paragraph (version B):
A 16-byte nonce exported from the HPKE encryption context.  See
send-ech for details about its computation.
Paragraph (version B):
Finally, requirements in client-behavior and server-behavior require
implementations to track, alongside each PSK established by a
previous connection, whether the connection negotiated this extension
with the "ech_accept" response type.  If so, this is referred to as
an "ECH PSK".  Otherwise, it is a "non-ECH PSK".  This may be
implemented by adding a new field to client and server session
states.
Paragraph (version A):
In order to send an encrypted ClientHello, the client first
determines if it supports the server's chosen KEM, as identified by
ECHOConfig.kem_id.  If one is supported, the client MUST select an
appropriate HpkeCipherSuite from the list of suites offered by the
server.  If the client does not support the corresponding KEM or is
unable to select an appropriate group or HpkeCipherSuite, it SHOULD
ignore that ECHOConfig value and MAY attempt to use another value
provided by the server.  The client MUST NOT send ECHO using HPKE
algorithms not advertised by the server.
Paragraph (version A):
Note that the HPKE algorithm identifiers are those which match the
client's chosen preference from ECHOConfig.cipher_suites.  The client
MAY replace any large, duplicated extensions in ClientHelloInner with
the corresponding "outer_extensions" extension, as described in
outer-extensions.
Paragraph (version B):
In order to send an encrypted ClientHello, the client first
determines if it supports the server's chosen KEM, as identified by
ECHConfig.kem_id.  If one is supported, the client MUST select an
appropriate HpkeCipherSuite from the list of suites offered by the
server.  If the client does not support the corresponding KEM or is
unable to select an appropriate group or HpkeCipherSuite, it SHOULD
ignore that ECHConfig value and MAY attempt to use another value
provided by the server.  The client MUST NOT send ECH using HPKE
algorithms not advertised by the server.
Paragraph (version B):
Note that the HPKE algorithm identifiers are those which match the
client's chosen preference from ECHConfig.cipher_suites.  The client
MAY replace any large, duplicated extensions in ClientHelloInner with
the corresponding "outer_extensions" extension, as described in
outer-extensions.
Paragraph (version A):
When offering an encrypted ClientHello, the client MUST NOT offer to
resume any non-ECHO PSKs.  It additionally MUST NOT offer to resume
any sessions for TLS 1.2 or below.
Paragraph (version B):
When offering an encrypted ClientHello, the client MUST NOT offer to
resume any non-ECH PSKs.  It additionally MUST NOT offer to resume
any sessions for TLS 1.2 or below.
Paragraph (version A):
The client MUST place the value of ECHOConfig.public_name in the
ClientHelloOuter "server_name" extension.  The ClientHelloOuter MUST
NOT contain a "cached_info" extension RFC7924 with a CachedObject
entry whose CachedInformationType is "cert", since this indication
would divulge the true server name.  The remaining contents of the
ClientHelloOuter MAY be identical to those in ClientHelloInner but
MAY also differ.
Paragraph (version B):
The client MUST place the value of ECHConfig.public_name in the
ClientHelloOuter "server_name" extension.  The ClientHelloOuter MUST
NOT contain a "cached_info" extension RFC7924 with a CachedObject
entry whose CachedInformationType is "cert", since this indication
would divulge the true server name.  The remaining contents of the
ClientHelloOuter MAY be identical to those in ClientHelloInner but
MAY also differ.
Paragraph (version A):
If L > D, add L - D bytes of padding.  This rounds to the server's
advertised hint, i.e., ECHOConfig.maximum_name_length.
Paragraph (version B):
If L > D, add L - D bytes of padding.  This rounds to the server's
advertised hint, i.e., ECHConfig.maximum_name_length.
Paragraph (version A):
As described in server-behavior, the server MAY either accept ECHO
and use ClientHelloInner or reject it and use ClientHelloOuter.
However, there is no indication in ServerHello of which one the
server has done and the client must therefore use trial decryption in
order to determine this.
Paragraph (version B):
As described in server-behavior, the server MAY either accept ECH and
use ClientHelloInner or reject it and use ClientHelloOuter.  However,
there is no indication in ServerHello of which one the server has
done and the client must therefore use trial decryption in order to
determine this.
Paragraph (version A):
If the server used ClientHelloOuter, the client proceeds with the
handshake, authenticating for ECHOConfig.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 keys.
Paragraph (version A):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"echo_required" alert.  It then processes the "retry_keys" field from
the server's "encrypted_client_hello" extension.
Paragraph (version A):
If one of the values contains a version supported by the client, it
can regard the ECHO 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 the server used ClientHelloOuter, the client proceeds with the
handshake, authenticating for ECHConfig.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 keys.
Paragraph (version B):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"ech_required" alert.  It then processes the "retry_keys" field from
the server's "encrypted_client_hello" extension.
Paragraph (version B):
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 A):
If none of the values provided in "retry_keys" contains a supported
version, the client can regard ECHO as securely disabled by the
server.  As below, it SHOULD then retry the handshake with a new
transport connection and ECHO disabled.
Paragraph (version B):
If none of the values provided in "retry_keys" 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 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
ECHOConfigContents.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 ECHO.
Paragraph (version A):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"echo_required" alert.  The client can then regard ECHO as securely
disabled by the server.  It SHOULD retry the handshake with a new
transport connection and ECHO disabled.
Paragraph (version A):
Clients SHOULD implement a limit on retries caused by
"echo_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 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
ECHConfigContents.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 B):
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 B):
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 A):
If the server resumed a session or negotiated a session that did
not use a certificate for authentication, the client MUST abort
the connection with an "illegal_parameter" alert.  This case is
invalid because send-echo requires the client to only offer ECHO-
established sessions, and server-behavior requires the server to
decline ECHO-established sessions if it did not accept ECHO.
Paragraph (version A):
The client MUST verify that the certificate is valid for
ECHOConfigContents.public_name.  If invalid, it MUST abort the
connection with the appropriate alert.
Paragraph (version B):
If the server resumed a session or negotiated a session that did
not use a certificate for authentication, the client MUST abort
the connection with an "illegal_parameter" alert.  This case is
invalid because send-ech requires the client to only offer ECH-
established sessions, and server-behavior requires the server to
decline ECH-established sessions if it did not accept ECH.
Paragraph (version B):
The client MUST verify that the certificate is valid for
ECHConfigContents.public_name.  If invalid, it MUST abort the
connection with the appropriate alert.
Paragraph (version A):
Clients then encrypt the second ClientHelloInner using this new HPKE
context.  In doing so, the encrypted value is also authenticated by
echo_hrr_key.  The rationale for this is described in flow-hrr-
hijack.
Paragraph (version B):
Clients then encrypt the second ClientHelloInner using this new HPKE
context.  In doing so, the encrypted value is also authenticated by
ech_hrr_key.  The rationale for this is described in flow-hrr-hijack.
Paragraph (version A):
Set the "encrypted_ch" field to a randomly-generated string of L
bytes, where L is the size of the ClientHelloInner message the
client would use given an ECHOConfig structure, padded according
to padding.
Paragraph (version B):
Set the "encrypted_ch" field to a randomly-generated string of L
bytes, where L is the size of the ClientHelloInner message the
client would use given an ECHConfig structure, padded according to
padding.
Paragraph (version A):
Offering a GREASE extension is not considered offering an encrypted
ClientHello for purposes of requirements in client-behavior.  In
particular, the client MAY offer to resume sessions established
without ECHO.
Paragraph (version B):
Offering a GREASE extension is not considered offering an encrypted
ClientHello for purposes of requirements in client-behavior.  In
particular, the client MAY offer to resume sessions established
without ECH.
Paragraph (version A):
Compare ClientEncryptedCH.record_digest against cryptographic
hashes of known ECHOConfig and choose the one that matches.
Paragraph (version A):
Use trial decryption of ClientEncryptedCH.encrypted_ch with known
ECHOConfig and choose the one that succeeds.
Paragraph (version A):
Some uses of ECHO, such as local discovery mode, may omit the
ClientEncryptedCH.record_digest since it can be used as a tracking
vector.  In such cases, trial decryption should be used for matching
ClientEncryptedCH to known ECHOConfig.  Unless specified by the
application using (D)TLS or externally configured on both sides,
implementations MUST use the first method.
Paragraph (version A):
It MUST include the "encrypted_client_hello" extension with the
"retry_keys" field set to one or more ECHOConfig structures with
up-to-date keys.  Servers MAY supply multiple ECHOConfig values of
different versions.  This allows a server to support multiple
versions at once.
Paragraph (version A):
The server MUST ignore all PSK identities in the ClientHello which
correspond to ECHO PSKs.  ECHO PSKs offered by the client are
associated with the ECHO name.  The server was unable to decrypt
then ECHO name, so it should not resume them when using the
cleartext SNI name.  This restriction allows a client to reject
resumptions in auth-public-name.
Paragraph (version A):
Note that an unrecognized ClientEncryptedCH.record_digest value may
be a GREASE ECHO extension (see grease-extensions), so it is
necessary for servers to proceed with the connection and rely on the
client to abort if ECHO was required.  In particular, the
unrecognized value alone does not indicate a misconfigured ECHO
advertisement (misconfiguration).  Instead, servers can measure
occurrences of the "echo_required" alert to detect this case.
Paragraph (version A):
If decryption fails, the server MUST abort the connection with a
"decrypt_error" alert.  Moreover, if there is no "echo_nonce"
extension, or if its value does not match the derived echo_nonce, the
server MUST abort the connection with a "decrypt_error" alert.  Next,
the server MUST scan ClientHelloInner for any "outer_extension"
extensions and substitute their values with the values in
ClientHelloOuter.  It MUST first verify that the hash found in the
extension matches the hash of the extension to be interpolated in and
if it does not, abort the connections with a "decrypt_error" alert.
Paragraph (version B):
Compare ClientEncryptedCH.record_digest against cryptographic
hashes of known ECHConfig and choose the one that matches.
Paragraph (version B):
Use trial decryption of ClientEncryptedCH.encrypted_ch with known
ECHConfig and choose the one that succeeds.
Paragraph (version B):
Some uses of ECH, such as local discovery mode, may omit the
ClientEncryptedCH.record_digest since it can be used as a tracking
vector.  In such cases, trial decryption should be used for matching
ClientEncryptedCH to known ECHConfig.  Unless specified by the
application using (D)TLS or externally configured on both sides,
implementations MUST use the first method.
Paragraph (version B):
It MUST include the "encrypted_client_hello" extension with the
"retry_keys" 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):
The server MUST ignore all PSK identities in the ClientHello which
correspond to ECH PSKs.  ECH PSKs offered by the client are
associated with the ECH name.  The server was unable to decrypt
then ECH name, so it should not resume them when using the
cleartext SNI name.  This restriction allows a client to reject
resumptions in auth-public-name.
Paragraph (version B):
Note that an unrecognized ClientEncryptedCH.record_digest value may
be a GREASE ECH extension (see grease-extensions), so it is necessary
for servers to proceed with the connection and rely on the client to
abort if ECH was required.  In particular, the unrecognized value
alone does not indicate a misconfigured ECH advertisement
(misconfiguration).  Instead, servers can measure occurrences of the
"ech_required" alert to detect this case.
Paragraph (version B):
If decryption fails, the server MUST abort the connection with a
"decrypt_error" alert.  Moreover, if there is no "ech_nonce"
extension, or if its value does not match the derived ech_nonce, the
server MUST abort the connection with a "decrypt_error" alert.  Next,
the server MUST scan ClientHelloInner for any "outer_extension"
extensions and substitute their values with the values in
ClientHelloOuter.  It MUST first verify that the hash found in the
extension matches the hash of the extension to be interpolated in and
if it does not, abort the connections with a "decrypt_error" alert.
Paragraph (version A):
If the server sends a NewSessionTicket message, the corresponding
ECHO PSK MUST be ignored by all other servers in the deployment when
not negotiating ECHO, including servers which do not implement this
specification.
Paragraph (version A):
However, in more complex deployment scenarios, this may be difficult
to fully guarantee.  Thus this protocol was designed to be robust in
case of inconsistencies between systems that advertise ECHO keys and
servers, at the cost of extra round-trips due to a retry.  Two
specific scenarios are detailed below.
Paragraph (version A):
It is possible for ECHO advertisements and servers to become
inconsistent.  This may occur, for instance, from DNS
misconfiguration, caching issues, or an incomplete rollout in a
multi-server deployment.  This may also occur if a server loses its
ECHO keys, or if a deployment of ECHO must be rolled back on the
server.
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 echo_retry_requested.  If the
server does not understand the "encrypted_client_hello" extension at
all, it will ignore it as required by RFC8446; Section 4.1.2.
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 A):
Unless ECHO is disabled as a result of successfully establishing a
connection to the public name, the client MUST NOT fall back to using
unencrypted ClientHellos, as this allows a network attacker to
disclose the contents of this ClientHello, including the SNI.  It MAY
attempt to use another server from the DNS results, if one is
provided.
Paragraph (version B):
If the server sends a NewSessionTicket message, the corresponding ECH
PSK MUST be ignored by all other servers in the deployment when not
negotiating ECH, including servers which do not implement this
specification.
Paragraph (version B):
However, in more complex deployment scenarios, this may be difficult
to fully guarantee.  Thus this protocol was designed to be robust in
case of inconsistencies between systems that advertise ECH keys and
servers, at the cost of extra round-trips due to a retry.  Two
specific scenarios are detailed below.
Paragraph (version B):
It is possible for ECH advertisements and servers to become
inconsistent.  This may occur, for instance, from DNS
misconfiguration, caching issues, or an incomplete rollout in a
multi-server deployment.  This may also occur if a server loses its
ECH keys, or if a deployment of ECH must be rolled back on the
server.
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 RFC8446; Section 4.1.2.
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):
Unless ECH is disabled as a result of successfully establishing a
connection to the public name, the client MUST NOT fall back to using
unencrypted ClientHellos, as this allows a network attacker to
disclose the contents of this ClientHello, including the SNI.  It MAY
attempt to use another server from the DNS results, if one is
provided.
Paragraph (version A):
Client-facing servers with non-uniform cryptographic configurations
across backend origin servers segment the ECHO anonymity set based on
these configurations.  For example, if a client-facing server hosts k
backend origin servers, and exactly one of those backend origin
servers supports a different set of cryptographic algorithms than the
other (k - 1) servers, it may be possible to identify this single
server based on the contents of the ServerHello as this message is
not encrypted.
Paragraph (version B):
Client-facing servers with non-uniform cryptographic configurations
across backend origin servers segment the ECH anonymity set based on
these configurations.  For example, if a client-facing server hosts k
backend origin servers, and exactly one of those backend origin
servers supports a different set of cryptographic algorithms than the
other (k - 1) servers, it may be possible to identify this single
server based on the contents of the ServerHello as this message is
not encrypted.
Paragraph (version A):
A more serious problem is MITM proxies which do not support this
extension.  RFC8446, Section 9.3 requires that such proxies remove
any extensions they do not understand.  The handshake will then
present a certificate based on the public name, without echoing the
"encrypted_client_hello" extension to the client.
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 ECHO.
Paragraph (version A):
A non-conformant MITM proxy which instead forwards the ECHO
extension, substituting its own KeyShare value, will result in the
client-facing server recognizing the key, but failing to decrypt the
SNI.  This causes a hard failure.  Clients SHOULD NOT attempt to
repair the connection in this case.
Paragraph (version A):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ECHO records have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches, which is a
common scenario in client access networks, can supply clients with
fake ECHO records (so that the client encrypts data to them) or strip
the ECHO record from the response.  However, in the face of an
attacker that controls DNS, no encryption scheme can work because the
attacker can replace the IP address, thus blocking client
connections, or substituting a unique IP address which is 1:1 with
the DNS name that was looked up (modulo DNS wildcards).  Thus,
allowing the ECHO records in the clear does not make the situation
significantly worse.
Paragraph (version B):
A more serious problem is MITM proxies which do not support this
extension.  RFC8446, Section 9.3 requires that such proxies remove
any extensions they do not understand.  The handshake will then
present a certificate based on the public name, without eching the
"encrypted_client_hello" extension to the client.
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 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):
A non-conformant MITM proxy which instead forwards the ECH extension,
substituting its own KeyShare value, will result in the client-facing
server recognizing the key, but failing to decrypt the SNI.  This
causes a hard failure.  Clients SHOULD NOT attempt to repair the
connection in this case.
Paragraph (version B):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ECH records have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches, which is a
common scenario in client access networks, can supply clients with
fake ECH records (so that the client encrypts data to them) or strip
the ECH record from the response.  However, in the face of an
attacker that controls DNS, no encryption scheme can work because the
attacker can replace the IP address, thus blocking client
connections, or substituting a unique IP address which is 1:1 with
the DNS name that was looked up (modulo DNS wildcards).  Thus,
allowing the ECH records in the clear does not make the situation
significantly worse.
Paragraph (version A):
A malicious client-facing server could distribute unique, per-client
ECHOConfig structures as a way of tracking clients across subsequent
connections.  On-path adversaries which know about these unique keys
could also track clients in this way by observing TLS connection
attempts.
Paragraph (version B):
A malicious client-facing server could distribute unique, per-client
ECHConfig structures as a way of tracking clients across subsequent
connections.  On-path adversaries which know about these unique keys
could also track clients in this way by observing TLS connection
attempts.
Paragraph (version A):
The cost of this type of attack scales linearly with the desired
number of target clients.  Moreover, DNS caching behavior makes
targeting individual users for extended periods of time, e.g., using
per-client ECHOConfig structures delivered via HTTPSSVC RRs with high
TTLs, challenging.  Clients can help mitigate this problem by
flushing any DNS or ECHOConfig state upon changing networks.
Paragraph (version B):
The cost of this type of attack scales linearly with the desired
number of target clients.  Moreover, DNS caching behavior makes
targeting individual users for extended periods of time, e.g., using
per-client ECHConfig structures delivered via HTTPSSVC RRs with high
TTLs, challenging.  Clients can help mitigate this problem by
flushing any DNS or ECHConfig state upon changing networks.
Paragraph (version A):
Optional record digests may be useful in scenarios where clients and
client-facing servers do not want to reveal information about the
client-facing server in the "encrypted_client_hello" extension.  In
such settings, servers must perform trial decrypt upon receipt of an
empty record digest, which may exacerbate DoS attacks.  Specifically,
an adversary may send malicious ClientHello messages, i.e., those
which will not decrypt with any known ECHO key, in order to force
wasteful decryption.  Servers that support this feature should, for
example, implement some form of rate limiting mechanism to limit the
damage caused by such attacks.
Paragraph (version A):
ECHO requires encrypted DNS to be an effective privacy protection
mechanism.  However, verifying the server's identity from the
Certificate message, particularly when using the X509
CertificateType, may result in additional network traffic that may
reveal the server identity.  Examples of this traffic may include
requests for revocation information, such as OCSP or CRL traffic, or
requests for repository information, such as
authorityInformationAccess.  It may also include implementation-
specific traffic for additional information sources as part of
verification.
Paragraph (version B):
Optional record digests may be useful in scenarios where clients and
client-facing servers do not want to reveal information about the
client-facing server in the "encrypted_client_hello" extension.  In
such settings, servers must perform trial decrypt upon receipt of an
empty record digest, which may exacerbate DoS attacks.  Specifically,
an adversary may send malicious ClientHello messages, i.e., those
which will not decrypt with any known ECH key, in order to force
wasteful decryption.  Servers that support this feature should, for
example, implement some form of rate limiting mechanism to limit the
damage caused by such attacks.
Paragraph (version B):
ECH requires encrypted DNS to be an effective privacy protection
mechanism.  However, verifying the server's identity from the
Certificate message, particularly when using the X509
CertificateType, may result in additional network traffic that may
reveal the server identity.  Examples of this traffic may include
requests for revocation information, such as OCSP or CRL traffic, or
requests for repository information, such as
authorityInformationAccess.  It may also include implementation-
specific traffic for additional information sources as part of
verification.
Paragraph (version A):
I-D.ietf-tls-sni-encryption lists several requirements for SNI
encryption.  In this section, we re-iterate these requirements and
assess the ECHO design against them.
Paragraph (version A):
Since servers process either ClientHelloInner or ClientHelloOuter,
and ClientHelloInner contains an HPKE-derived nonce, it is not
possible for an attacker to "cut and paste" the ECHO value in a
different Client Hello and learn information from ClientHelloInner.
This is because the attacker lacks access to the HPKE-derived nonce
used to derive the handshake secrets.
Paragraph (version B):
I-D.ietf-tls-sni-encryption lists several requirements for SNI
encryption.  In this section, we re-iterate these requirements and
assess the ECH design against them.
Paragraph (version B):
Since servers process either ClientHelloInner or ClientHelloOuter,
and ClientHelloInner contains an HPKE-derived nonce, it is not
possible for an attacker to "cut and paste" the ECH value in a
different Client Hello and learn information from ClientHelloInner.
This is because the attacker lacks access to the HPKE-derived nonce
used to derive the handshake secrets.
Paragraph (version A):
This design depends upon DNS as a vehicle for semi-static public key
distribution.  Server operators may partition their private keys
however they see fit provided each server behind an IP address has
the corresponding private key to decrypt a key.  Thus, when one ECHO
key is provided, sharing is optimally bound by the number of hosts
that share an IP address.  Server operators may further limit sharing
by publishing different DNS records containing ECHOConfig values with
different keys using a short TTL.
Paragraph (version B):
This design depends upon DNS as a vehicle for semi-static public key
distribution.  Server operators may partition their private keys
however they see fit provided each server behind an IP address has
the corresponding private key to decrypt a key.  Thus, when one ECH
key is provided, sharing is optimally bound by the number of hosts
that share an IP address.  Server operators may further limit sharing
by publishing different DNS records containing ECHConfig values with
different keys using a short TTL.
Paragraph (version A):
The only explicit signal indicating possible use of ECHO is the
ClientHello "encrypted_client_hello" extension.  Server handshake
messages do not contain any signal indicating use or negotiation of
ECHO.  Clients MAY GREASE the "encrypted_client_hello" extension, as
described in grease-extensions, which helps ensure the ecosystem
handles ECHO correctly.  Moreover, as more clients enable ECHO
support, e.g., as normal part of Web browser functionality, with keys
supplied by shared hosting providers, the presence of ECHO extensions
becomes less unusual and part of typical client behavior.  In other
words, if all Web browsers start using ECHO, the presence of this
value will not signal unusual behavior to passive eavesdroppers.
Paragraph (version A):
This design is not forward secret because the server's ECHO key is
static.  However, the window of exposure is bound by the key
lifetime.  It is RECOMMENDED that servers rotate keys frequently.
Paragraph (version B):
The only explicit signal indicating possible use of ECH is the
ClientHello "encrypted_client_hello" extension.  Server handshake
messages do not contain any signal indicating use or negotiation of
ECH.  Clients MAY GREASE the "encrypted_client_hello" extension, as
described in grease-extensions, which helps ensure the ecosystem
handles ECH correctly.  Moreover, as more clients enable ECH support,
e.g., as normal part of Web browser functionality, with keys supplied
by shared hosting providers, the presence of ECH extensions becomes
less unusual and part of typical client behavior.  In other words, if
all Web browsers start using ECH, the presence of this value will not
signal unusual behavior to passive eavesdroppers.
Paragraph (version B):
This design is not forward secret because the server's ECH key is
static.  However, the window of exposure is bound by the key
lifetime.  It is RECOMMENDED that servers rotate keys frequently.
Paragraph (version A):
Assuming ECHO records retrieved from DNS are authenticated, e.g., via
DNSSEC or fetched from a trusted Recursive Resolver, spoofing a
server operating in Split Mode is not possible.  See cleartext-dns
for more details regarding cleartext DNS.
Paragraph (version A):
Authenticating the ECHOConfigs structure naturally authenticates the
included public name.  This also authenticates any retry signals from
the server because the client validates the server certificate
against the public name before retrying.
Paragraph (version B):
Assuming ECH records retrieved from DNS are authenticated, e.g., via
DNSSEC or fetched from a trusted Recursive Resolver, spoofing a
server operating in Split Mode is not possible.  See cleartext-dns
for more details regarding cleartext DNS.
Paragraph (version B):
Authenticating the ECHConfigs structure naturally authenticates the
included public name.  This also authenticates any retry signals from
the server because the client validates the server certificate
against the public name before retrying.
Paragraph (version A):
This section describes the rationale for ECHO properties and
mechanics as defenses against active attacks.  In all the attacks
below, the attacker is on-path between the target client and server.
The goal of the attacker is to learn private information about the
inner ClientHello, such as the true SNI value.
Paragraph (version B):
This section describes the rationale for ECH properties and mechanics
as defenses against active attacks.  In all the attacks below, the
attacker is on-path between the target client and server.  The goal
of the attacker is to learn private information about the inner
ClientHello, such as the true SNI value.
Paragraph (version A):
The "echo_nonce" extension in the inner ClientHello prevents this
attack.  In particular, since the attacker does not have access to
this value, it cannot produce the right transcript and handshake keys
needed for encrypting the Certificate message.  Thus, the client will
fail to decrypt the Certificate and abort the connection.
Paragraph (version B):
The "ech_nonce" extension in the inner ClientHello prevents this
attack.  In particular, since the attacker does not have access to
this value, it cannot produce the right transcript and handshake keys
needed for encrypting the Certificate message.  Thus, the client will
fail to decrypt the Certificate and abort the connection.
Paragraph (version A):
This attack aims to exploit server HRR state management to recover
information about a legitimate ClientHello using its own attacker-
controlled ClientHello.  To begin, the attacker intercepts and
forwards a legitimate ClientHello with an "encrypted_client_hello"
(echo) extension to the server, which triggers a legitimate
HelloRetryRequest in return.  Rather than forward the retry to the
client, the attacker, attempts to generate its own ClientHello in
response based on the contents of the first ClientHello and
HelloRetryRequest exchange with the result that the server encrypts
the Certificate to the attacker.  If the server used the SNI from the
first ClientHello and the key share from the second (attacker-
controlled) ClientHello, the Certificate produced would leak the
client's chosen SNI to the attacker.
Paragraph (version B):
This attack aims to exploit server HRR state management to recover
information about a legitimate ClientHello using its own attacker-
controlled ClientHello.  To begin, the attacker intercepts and
forwards a legitimate ClientHello with an "encrypted_client_hello"
(ech) extension to the server, which triggers a legitimate
HelloRetryRequest in return.  Rather than forward the retry to the
client, the attacker, attempts to generate its own ClientHello in
response based on the contents of the first ClientHello and
HelloRetryRequest exchange with the result that the server encrypts
the Certificate to the attacker.  If the server used the SNI from the
first ClientHello and the key share from the second (attacker-
controlled) ClientHello, the Certificate produced would leak the
client's chosen SNI to the attacker.
Paragraph (version A):
This attack is mitigated by binding the first and second ClientHello
messages together.  In particular, since the attacker does not
possess the echo_hrr_key, it cannot generate a valid encryption of
the second inner ClientHello.  The server will attempt decryption
using echo_hrr_key, detect failure, and fail the connection.
Paragraph (version B):
This attack is mitigated by binding the first and second ClientHello
messages together.  In particular, since the attacker does not
possess the ech_hrr_key, it cannot generate a valid encryption of the
second inner ClientHello.  The server will attempt decryption using
ech_hrr_key, detect failure, and fail the connection.
Paragraph (version A):
ECHO mitigates against this attack by requiring servers not mix-and-
match information from the inner and outer ClientHello.  For example,
if the server accepts the inner ClientHello, it does not validate
binders in the outer ClientHello.  This means that ECHO PSKs are used
within the HPKE encryption envelope.
Paragraph (version B):
ECH mitigates against this attack by requiring servers not mix-and-
match information from the inner and outer ClientHello.  For example,
if the server accepts the inner ClientHello, it does not validate
binders in the outer ClientHello.  This means that ECH PSKs are used
within the HPKE encryption envelope.
Paragraph (version A):
IANA is requested to create an entry, echo_required(121) in the
existing registry for Alerts (defined in RFC8446), with the "DTLS-OK"
column being set to "Y".
Paragraph (version B):
IANA is requested to create an entry, ech_required(121) in the
existing registry for Alerts (defined in RFC8446), with the "DTLS-OK"
column being set to "Y".