Draft: draft-ietf-tls-esni

Commentary: In places , the current draft does n't make a clear distinction between rejection and decryption failure . In particular " can not decrypt " can be interpreted either : " the client - facing server does n't recognize the configuration specified by the client " ; or " the client - facing server recognizes the configuration but decryption fails " . This change resolves this ambiguity . Addresses issue . 
 Two sections suggest to ignore the extension on decryption failure , but one suggests to send an alert . What should happen ? Ignoring the extension on unrecognized failures sounds reasonable in order to " not stick out " . However , it is not entirely unambiguous what to do if a valid ECHConfig is found but decryption fails . says : says : says : 
 I think the first two statements apply when the config_digest does n't correspond to a known ECHConfig ( i.e. , " I ca n't decrypt this " ) ; the last is when the ECHConfig is known , but decryption fails ( " I should be able to decrypt this , but the ciphertext is invalid " ) . The text could be a lot clearer here . 
 Yes , your interpretation is correct . I think this is the result of a number of uncoordinated changes . 
 Closing as resolved .
Paragraph (version A):
When a client wants to establish a TLS session with the backend
server, it constructs its ClientHello as usual (we will refer to this
as the ClientHelloInner message) and then encrypts this message using
the ECH public key.  It then constructs a new ClientHello
(ClientHelloOuter) with innocuous values for sensitive extensions,
e.g., SNI, ALPN, etc., and with the encrypted ClientHelloInner in an
"encrypted_client_hello" extension, which this document defines
(encrypted-client-hello).  Finally, it sends ClientHelloOuter to the
server.
Paragraph (version B):
When a client wants to establish a TLS session with the backend
server, it constructs its ClientHello as usual (we will refer to this
as the ClientHelloInner message) and then encrypts this message using
the public key of the ECH configuration.  It then constructs a new
ClientHello (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 supports ECH but cannot decrypt it, then it ignores the
extension and proceeds with the handshake as usual.  This is
referred to as "ECH rejection".  When ECH is rejected, the server
sends an acceptable ECH configuration in its EncryptedExtensions
message.
Paragraph (version A):
If it supports ECH and can decrypt it, then it forwards the
ClientHelloInner to the backend, who terminates the connection.
This is referred to as "ECH acceptance".
Paragraph (version B):
If it supports ECH but does not recognize the configuration
specified by the client, then it ignores the extension and
terminates the handshake using the ClientHelloOuter.  This is
referred to as "ECH rejection".  When ECH is rejected, the server
sends an acceptable ECH configuration in its EncryptedExtensions
message.
Paragraph (version B):
If it supports ECH and recognizes the configuration, then it
attempts to decrypt the ClientHelloInner.  It aborts the handshake
if decryption fails; otherwise it forwards the ClientHelloInner to
the backend, who terminates the connection.  This is referred to
as "ECH acceptance".