Draft: draft-ietf-tls-esni

Commentary: The overview was a bit long , and slightly inaccurate . The ClientHelloInner is encrypted after ( most ) of the ClientHelloOuter is constructed . I 've also merged the ECH - naive server case with the ECH rejection case . This is more consistent with the client text , and most other TLS extensions , where we do not distinguish between reasons why the extension could not be negotiated . I 've also generally tightened up the wording to make it shorter . As part of that , I 'm trimmed the repeated list of sensitive ClientHello extensions . ECH itself is ( mostly ) agnostic to which extensions you believe are sensitive , and we already gave examples in the introduction .
Paragraph (version A):
ECH allows the client to encrypt sensitive ClientHello extensions,
e.g., SNI, ALPN, etc., under the public key of the client-facing
server.  This requires the client-facing server to publish the public
key and metadata it uses for ECH for all the domains for which it
serves directly or indirectly (via Split Mode).  This document
defines the format of the ECH encryption public key and metadata,
referred to as an ECH configuration, and delegates DNS publication
details to HTTPS-RR, 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 establish a TLS session with the backend
server, it constructs its ClientHello as indicated in real-ech.  We
will refer to this as the ClientHelloInner message.  The client
encrypts this message using the public key of the ECH configuration.
It then constructs a new ClientHello, the ClientHelloOuter, with
innocuous values for sensitive extensions, e.g., SNI, ALPN, etc., and
with an "encrypted_client_hello" extension, which this document
defines (encrypted-client-hello).  The extension's payload carries
the encrypted ClientHelloInner and specifies the ECH configuration
used for encryption.  Finally, it sends ClientHelloOuter to the
server.
Paragraph (version A):
If it does not support ECH, it ignores the
"encrypted_client_hello" extension and proceeds with the handshake
as usual, per RFC8446, Section 4.1.2.
Paragraph (version A):
If it is a client-facing server for the ECH protocol, but cannot
decrypt the extension, then it terminates the handshake using the
ClientHelloOuter.  This is referred to as "ECH rejection".  When
ECH is rejected, the client-facing server sends an acceptable ECH
configuration in its EncryptedExtensions message.
Paragraph (version A):
If it supports ECH and decrypts the extension, it forwards the
ClientHelloInner to the backend server, who terminates the
connection.  This is referred to as "ECH acceptance".
Paragraph (version B):
A client-facing server enables ECH by publishing an ECH
configuration, which is an encryption public key and associated
metadata.  The server must publish this for all the domains it serves
via Shared or Split Mode.  This document defines the ECH
configuration's format, but delegates DNS publication details to
HTTPS-RR.  Other delivery mechanisms are also possible.  For example,
the client may have the ECH configuration preconfigured.
Paragraph (version B):
When a client wants to establish a TLS session with some backend
server, it constructs a private ClientHello, referred to as the
ClientHelloInner.  The client then constructs a public ClientHello,
referred to as the ClientHelloOuter.  The ClientHelloOuter contains
innocuous values for sensitive extensions and an
"encrypted_client_hello" extension (encrypted-client-hello), which
carries the encrypted ClientHelloInner.  Finally, the client sends
ClientHelloOuter to the server.
Paragraph (version B):
If it does not support ECH or cannot decrypt the extension, it
completes the handshake with ClientHelloOuter.  This is referred
to as rejecting ECH.
Paragraph (version B):
If it successfully decrypts the extension, it forwards the
ClientHelloInner to the backend server, which completes the
handshake.  This is referred to as accepting ECH.
Paragraph (version B):
Upon receiving the server's response, the client determines whether
or not ECH was accepted (handle-server-response) and proceeds with
the handshake accordingly.  When ECH is rejected, the resulting
connection is not usable by the client for application data.
Instead, ECH rejection allows the client to retry with up-to-date
configuration (rejected-ech).
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 ECH.
Paragraph (version B):
Offering a GREASE extension is not considered offering an encrypted
ClientHello for purposes of requirements in real-ech.  In particular,
the client MAY offer to resume sessions established without ECH.