Draft: draft-ietf-tls-esni

Commentary: Addresses . This is for motivating some of our design decisions ( and documenting what we know along the way ) . I meant to do this a while ago , but never got around to it . In particular , it describes why we have the following three bindings : to ECHO secret ( to prevent client reaction attacks ) . 1 to CH2 ( to prevent  oracles ) . to resumption PSK binder ( to prevent resumption oracles ) . I 'm sure the language and presentation can be improved , so suggestions to that effect are very much welcome ! cc 
 Thanks for the feedback ! I incorporated your suggestions and clarified a few more things . I 'm merging as - is since they seemed mostly editorial . 
 < img width="909 " alt="Screen Shot 2020 - 05 - 02 at 3 33 05 PM " src="https://user- " 
 Addressed in .
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.
Paragraph (version B):
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):
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 attack uses the client's reaction to an incorrect certificate as
an oracle.  The attacker intercepts a legitimate ClientHello and
replies with a ServerHello, Certificate, CertificateVerify, and
Finished messages, wherein the Certificate message contains a "test"
certificate for the domain name it wishes to query.  If the client
decrypted the Certificate and failed verification (or leaked
information about its verification process by a timing side channel),
the attacker learns that its test certificate name was incorrect.  As
an example, suppose the client's SNI value in its inner ClientHello
is "example.com," and the attacker replied with a Certificate for
"test.com".  If the client produces a verification failure alert
because of the mismatch faster than it would due to the Certificate
signature validation, information about the name leaks.  Note that
the attacker can also withhold the CertificateVerify message.  In
that scenario, a client which first verifies the Certificate would
then respond similarly and leak the same information.
Paragraph (version B):
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):
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 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 uses resumption PSKs as an oracle for dictionary attacks
against a given ClientHello's true SNI.  To begin, the attacker first
interacts with a server to obtain a resumption ticket for a given
test domain, such as "test.com".  Later, upon receipt of a legitimate
ClientHello without a PSK binder, it computes a PSK binder using its
own ticket and forwards the resulting ClientHello.  Assume the server
then validates the PSK binder on the outer ClientHello and chooses
connection parameters based on the inner ClientHello.  A server which
then validates information in the outer ClientHello ticket against
information in the inner ClientHello, such as the SNI, introduces an
oracle that can be used to test the encrypted SNI value of specific
ClientHello messages.
Paragraph (version B):
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.