Draft: draft-ietf-tls-esni

Commentary: Currently we distinguish between CHI and CHO by sending " echisinner " in CHI and " encryptedclienthello " in CHO . A future change will signal ECH acceptance in HRR using the " encryptedclienthello " codepoint . This would violate 8446 's rule that disallows unsolicited extensions . In preparation for this change , this commit removes the " echisinner " extension and adds a byte to the payload of " encryptedclienthello " that signals to the server whether the message is CHI or CHO . 
 Rebased and squashed . 
 Rebased .
Paragraph (version B):
To offer ECH, the client sends an "encrypted_client_hello" extension
in the ClientHelloOuter.  When it does, it MUST also send the
extension in ClientHelloInner.
Paragraph (version B):
The response is valid only when the server used the ClientHelloOuter.
If the server sent this extension in response to the "inner" variant,
then the client MUST abort with an "unsupported_extension" alert.
Paragraph (version A):
If, in a ClientHello, the "encrypted_client_hello" extension is not
present and an "ech_is_inner" extension is present, the ClientHello
is a ClientHelloInner.  This extension MUST only be sent in the
ClientHello message.
Paragraph (version A):
The "extension_data" field of the "ech_is_inner" extension is zero
length.
Paragraph (version A):
Backend servers (as described in server-behavior) MUST support the
"ech_is_inner" extension.
Paragraph (version A):
If both the "ech_is_inner" and "encrypted_client_hello" extensions
are present in the ClientHello, the backend server MUST abort with
an "illegal_parameter" alert.
Paragraph (version A):
If only the "encrypted_client_hello" extension is present, the
server acts as a client-facing server and proceeds as described in
client-facing-server to extract a ClientHelloInner, if available.
Paragraph (version A):
If only the "ech_is_inner" extension is present and the
"encrypted_client_hello" extension is not present, the server acts
as a backend server and proceeds as described in backend-server.
Paragraph (version A):
If neither extension is present, the server completes the
handshake normally, as described in RFC8446.
Paragraph (version B):
If "ClientECH.type" is "outer", then the server acts as a client-
facing server and proceeds as described in client-facing-server to
extract a ClientHelloInner, if available.
Paragraph (version B):
If "ClientECH.type" is "inner", then the server acts as a backend
server and proceeds as described in backend-server.
Paragraph (version B):
Otherwise, if "ClientECH.type" is not a valid "ClientECHType",
then the server MUST abort with an "illegal_parameter" alert.
Paragraph (version B):
If the "encrypted_client_hello" is not present, then the server
completes the handshake normally, as described in RFC8446.
Paragraph (version A):
If the client offers the "ech_is_inner" extension (is-inner) in
addition to the "encrypted_client_hello" extension, the server MUST
abort with an "illegal_parameter" alert.
Paragraph (version A):
Upon determining the ClientHelloInner, the client-facing server then
checks that the message includes the "ech_is_inner" extension, omits
the "encrypted_client_hello" extension, and does not offer TLS 1.2 or
below versions.  If any of these checks fails, the client-facing
server MUST abort with an "illegal_parameter" alert.
Paragraph (version B):
Upon determining the ClientHelloInner, the client-facing server
checks that the message includes a well-formed
"encrypted_client_hello" extension of type "inner" and that it does
not offer TLS 1.2 or below.  If either of these checks fails, the
client-facing server MUST abort with an "illegal_parameter" alert.
Paragraph (version A):
Upon receipt of an "ech_is_inner" extension in a ClientHello, if the
backend server negotiates TLS 1.3 or higher, then it MUST confirm ECH
acceptance to the client by computing its ServerHello as described
here.
Paragraph (version B):
Upon receipt of an "encrypted_client_hello" extension of type "inner"
in a ClientHello, if the backend server negotiates TLS 1.3 or higher,
then it MUST confirm ECH acceptance to the client by computing its
ServerHello as described here.
Paragraph (version A):
The "ech_is_inner" is expected to have an empty payload.  If the
payload is non-empty (i.e., the length of the "extension_data" field
is non-zero) then the backend server MUST abort the handshake with an
"illegal_parameter" alert.
Paragraph (version A):
ech_is_inner (0xda09), with "TLS 1.3" column values set to "CH",
and "Recommended" column set to "Yes".