Draft: draft-ietf-tls-esni

Commentary: ( WG email coming shortly . ) Update : This has been rebased to master , now that is merged . The new server behavior ( " Improve ESNI robustness " ) means clients can send GREASE ESNI extensions without interop issues . Write some text recommending this , better meeting the " Do not stick out " criteria . 
 The GREASE section seems fine to me . ( is there other new material in this PR ? ) please have a look when possible . 
 It 's whatever 's in the second commit , so mostly that section but also a bit elsewhere : 
 I share the view that the GREASE section looks fine . 
 Did you mean to leave the comments on ( Notably the text already has seen a number of revisions here . I have n't gone back to update this PR yet . This PR was meant to just be the second commit . ) 
 Ugh . Having something which claims to be a merged PR is kind of an attractive nusiance , then , no ? Perhaps you can apply the changes here ? 
 In my defense , I split them at your request and did include the following . ;-) But , sure , I can rebase this one . I figured was the bulk of the interesting bits ( is much smaller ) so I figured we 'd first and then I 'd update this one at the end . 
 Sure , and I read that as " this is an accurate reflection of my put for both of these " . But , sure , I can rebase this one . I figured Thanks . 
 Well , it was when I wrote that sentence . :-) Anyway , it 's now been rebased and I 've incorporated your comments as well .
Paragraph (version A):
If the value is "esni_accept", the client MUST check that the
extension's "nonce" field matches ClientESNIInner.nonce and
otherwise abort the connection with an "illegal_parameter" alert.
The client then proceeds with the connection as usual, verifying
the certificate against the desired name.
Paragraph (version A):
If the value is "esni_retry_request", the client proceeds with the
handshake, verifying the certificate against ESNIKeys.public_name
as described in verify-public-name.  If verification 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 verified, the client MUST abort the connection with an
"esni_required" alert.  It then processes the "retry_keys" field
from the server's "encrypted_server_name" extension.
Paragraph (version B):
If the value is "esni_accept", the client MUST check that the
extension's "nonce" field matches ClientESNIInner.nonce and
otherwise abort the connection with an "illegal_parameter" alert.
The client then proceeds with the connection as usual,
authenticating the connection for the origin server.
Paragraph (version B):
If the value is "esni_retry_request", the client proceeds with the
handshake, authenticating for ESNIKeys.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 "esni_required" alert.  It then processes the "retry_keys"
field from the server's "encrypted_server_name" extension.
Paragraph (version A):
If the server negotiates an earlier version of TLS, or if it does not
provide an "encrypted_server_name" extension in EncryptedExtensions,
the client proceeds with the handshake, verifying the certificate
against ESNIKeys.public_name as described in verify-public-name.  The
client MUST NOT enable the False Start optimization RFC7918 for this
handshake.  If verification 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 ESNI.
Paragraph (version A):
Otherwise, when the handshake completes successfully with the public
name verified, the client MUST abort the connection with an
"esni_required" alert.  The client can then regard ESNI as securely
disabled by the server.  It SHOULD retry the handshake with a new
transport connection and ESNI disabled.
Paragraph (version B):
If the server negotiates an earlier version of TLS, or if it does not
provide an "encrypted_server_name" extension in EncryptedExtensions,
the client proceeds with the handshake, authenticating for
ESNIKeys.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
ESNI.
Paragraph (version B):
Otherwise, when the handshake completes successfully with the public
name authenticated, the client MUST abort the connection with an
"esni_required" alert.  The client can then regard ESNI as securely
disabled by the server.  It SHOULD retry the handshake with a new
transport connection and ESNI disabled.
Paragraph (version A):
Note that verifying a connection for the public name does not verify
it for the origin.  The TLS implementation MUST NOT report such
connections as successful to the application.  It additionally MUST
ignore all session tickets and session IDs presented by the server.
These connections are only used to trigger retries, as described in
handle-server-response.  This may be implemented, for instance, by
reporting a failed connection with a dedicated error code.
Paragraph (version B):
Note that authenticating a connection for the public name does not
authenticate it for the origin.  The TLS implementation MUST NOT
report such connections as successful to the application.  It
additionally MUST ignore all session tickets and session IDs
presented by the server.  These connections are only used to trigger
retries, as described in handle-server-response.  This may be
implemented, for instance, by reporting a failed connection with a
dedicated error code.
Paragraph (version B):
Select a supported cipher suite, named group, and padded_length
value.  The padded_length value SHOULD be 260.  Set the "suite"
field to the selected cipher suite.
Paragraph (version B):
Set the "key_share" field to a randomly-generated valid public key
for the named group.
Paragraph (version B):
Set the "record_digest" field to a randomly-generated string of
hash_length bytes, where hash_length is the length of the hash
function associated with the chosen cipher suite.
Paragraph (version B):
Set the "encrypted_sni" field to a randomly-generated string of 16
+ padded_length + tag_length bytes, where tag_length is the tag
length of the chosen cipher suite's associated AEAD.
Paragraph (version B):
If the server sends an "encrypted_server_name" extension, the client
MUST check the extension syntactically and abort the connection with
a "decode_error" alert if it is invalid.  If the "response_type"
field contains "esni_retry_requested", the client MUST ignore the
extension and proceed with the handshake.  If it contains
"esni_accept" or any other value, the client MUST abort the
connection with an "illegal_parameter" alert.
Paragraph (version B):
Offering a GREASE extension is not considered offering an encrypted
SNI for purposes of requirements in client-behavior.  In particular,
the client MAY offer to resume sessions established without ESNI.
Paragraph (version A):
The server MUST ignore all PSK identities in the ClientHello which
correspond to ESNI PSKs.  ESNI PSKs offered by the client are
associated with the ESNI name.  The server was unable to decrypt
then ESNI name, so it should not resume them when using the
cleartext SNI name.  This restriction allows a client to reject
resumptions in verify-public-name.
Paragraph (version B):
The server MUST ignore all PSK identities in the ClientHello which
correspond to ESNI PSKs.  ESNI PSKs offered by the client are
associated with the ESNI name.  The server was unable to decrypt
then ESNI 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 ClientEncryptedSNI.record_digest value may
be a GREASE ESNI extension (see grease-extensions), so it is
necessary for servers to proceed with the connection and rely on the
client to abort if ESNI was required.  In particular, the
unrecognized value alone does not indicate a misconfigured ESNI
advertisement (misconfiguration).  Instead, servers can measure
occurrences of the "esni_required" alert to detect this case.
Paragraph (version A):
If the server sends a NewSessionTicket message, the corresponding
ESNI PSK MUST be ignored by all other servers in the deployment when
not negotiating ESNI, including servers which do not implement this
specification.  This may be implemented by adding a new field to the
server session state which earlier implementations cannot parse.
Paragraph (version B):
If the server sends a NewSessionTicket message, the corresponding
ESNI PSK MUST be ignored by all other servers in the deployment when
not negotiating ESNI, including servers which do not implement this
specification.
Paragraph (version A):
The retry mechanism repairs most such inconsistencies.  If server and
advertised keys mismatch, the server will respond with
esni_retry_requested.  If the server does not understand the
"encrypted_server_name" 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):
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 esni_retry_requested.  If the
server does not understand the "encrypted_server_name" 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):
Additionally, this specification allows for clients to send GREASE
ESNI extensions (see grease-extensions), which helps ensure the
ecosystem handles the values correctly.