Draft: draft-rescorla-tls-esni

Commentary: Current text says : the " encryptedservername " extension . However , I am not sure if this is the desired behavior . I would rather suggest encrypting even when the hostname exceeds the paddedlength . Having some protection is better than none . The issue is that in certain deployments it is impossible to guess what the maximum length of the hostname will be . Consider . It uses a wildcard certificate . Anybody can add a new hostname of any length by creating a new  account ( it might be true that  some limitation on the length , but that does not necessarily mean that Github shares the maximum length information with the fronting CDN , assuming that it uses a CDN ) . 
 I have filed that fixes another issue ( it 's just a clarification of an open issue ) related to wildcard delegation . 
 Technically , it is possible to guess the maximum length of the hostname , as that maximum textual representation length is defined as 253 bytes per RFC 1034 . 
 Yes . So the question is if a CDN that has a wildcard mapping needs to set to 253 ( since current text is a MUST NOT for sending a server name longer than the paddedlength ) , or if we should introduce a different rule . 
 How about something like : padded_length : The length to pad the ServerNameList value to prior to encryption . This value SHOULD be set to the largest ServerNameList the fronting server expects to support rounded up the nearest multiple of 16 . If the fronting server supports wildcard names , it SHOULD set this value to 256 . 
 Thank you for the suggestion . I was feeling uneasy ( and am still feeling a bit ) about requiring the client to send an ESNI extension as large as ~300 bytes , assuming that CDN 's would have at least one wildcard mappings . But it 's about the first packet sent from the client , and we typically have enough room even when 0 - RTT data is involved . So I think that we can live with that . 
 To be 
 Thank you for working on this ! LGTM aside from the two comments shown below . Sorry , I missed the padding thing , so you 'll need to adjust
Paragraph (version A):
First four (4) octets of the SHA-256 message digest RFC6234 of the
ESNIKeys structure starting from the first octet of "keys" to the
end of the stucture.
Paragraph (version A):
The length to pad the ServerNameList value to prior to encryption.
This value SHOULD be set to the largest ServerNameList the server
expects to support rounded up the nearest multiple of 16.
Paragraph (version B):
First four (4) octets of the SHA-256 message digest RFC6234 of the
ESNIKeys structure starting from the first octet of "keys" to the
end of the structure.
Paragraph (version B):
The length to pad the ServerNameList value to prior to encryption.
This value SHOULD be set to the largest ServerNameList the server
expects to support rounded up the nearest multiple of 16.  If the
server supports wildcard names, it SHOULD set this value to 256.
Paragraph (version A):
Assuming that these checks succeed, the server then computes K_sni
and decrypts the ServerName value.  If decryption fails, the server
MUST abort the connection with a "decrypt_error" alert.
Paragraph (version B):
Assuming these checks succeed, the server then computes K_sni and
decrypts the ServerName value.  If decryption fails, the server MUST
abort the connection with a "decrypt_error" alert.
Paragraph (version B):
A server operating in Shared Mode uses PaddedServerNameList.sni as if
it were the "server_name" extension to finish the handshake.  It
SHOULD pad the Certificate message, via padding at the record layer,
such that its length equals the size of the largest possible
Certificate (message) covered by the same ESNI key.
Paragraph (version B):
The Hidden Server ignores both the "encrypted_server_name" and the
"server_name" (if any) and completes the handshake as usual.  If in
Shared Mode, the server will still know the true SNI, and can use it
for certificate selection.  In Split Mode, it may not know the true
SNI and so will generally be configured to use a single certificate.
communicating-sni describes a mechanism for communicating the true
SNI to the hidden server.
Paragraph (version B):
Similar to the Shared Mode behavior, the hidden server in Split Mode
SHOULD pad the Certificate message, via padding at the record layer
such that its length equals the size of the largest possible
Certificate (message) covered by the same ESNI key.
Paragraph (version A):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ESNIKeys have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches, which is a
common scenario in client access netowrks, can supply clients with
fake ESNIKeys (so that the client encrypts SNI to them) or strip the
ESNIKeys from the response.  However, in the face of an attacker that
controls DNS, no SNI encryption scheme can work because the attacker
can replace the IP address, thus blocking client connections, or
substituting a unique IP address which is 1:1 with the DNS name that
was looked up (module DNS wildcards).  Thus, allowing the ESNIKeys in
the clear does not make the situation significantly worse.
Paragraph (version B):
In comparison to I-D.kazuho-protected-sni, wherein DNS Resource
Records are signed via a server private key, ESNIKeys have no
authenticity or provenance information.  This means that any attacker
which can inject DNS responses or poison DNS caches, which is a
common scenario in client access networks, can supply clients with
fake ESNIKeys (so that the client encrypts SNI to them) or strip the
ESNIKeys from the response.  However, in the face of an attacker that
controls DNS, no SNI encryption scheme can work because the attacker
can replace the IP address, thus blocking client connections, or
substituting a unique IP address which is 1:1 with the DNS name that
was looked up (module DNS wildcards).  Thus, allowing the ESNIKeys in
the clear does not make the situation significantly worse.