Draft: draft-ietf-tls-esni

Commentary: how does this look to you ? The discussion on how to allocate configids made it very unclear whether we cared about collisions in DNS or across client - facing servers . ( The former is insufficient and the latter is practically impossible . ) Instead , pull this into a separate section , so we can be clear this is a recommendation for the client - facing server and the backend server . Also downgrade from MUST to SHOULD because collisions work fine , just do n't perform as well . It was also weird that we talked about configid in not the section about config_ids , but in the little side note about HpkeKeyConfig . 
 I went with " known " instead of " active " since { { client - facing - server } } already used " known " . It just never defined it , so I guess now we have a definition or sorts . :-) 
 That looks good , better than I 'd suggested . I guess I 'll close the other one in a few minutes ( just to give someone time to correct me that that 's not the right button - pushing:- ) Thanks , S. 
 2 Middleboxes identifies a legitimate concern where middleboxes might strip a new ESNI extension that is unknown to them . The ServerName structure as defined in RFC 6066 has an 8 - bit NameType field where 0 is defined as hostname and all other values are undefined . Why not define 1 ( or any other value ) as encryptedhostname ? The name structure inside ServerName is 16 opaque bits which seems able to accommodate EncryptedSNI as defined in this document . ( Make encryptedsni slightly smaller so that " label " and " suite " fit ) 
 I prefer having a different extension , because we do not want to limit the capability of ESNIKeys to just protecting the " HostName " ( as identified by the 8 - bit NameType field of zero ) . IMO it is better to have a mechanism that can protect any type of " server - name " , including those covered by NameTypes other than zero . Note that DNS is just one way of publishing ESNIKeys . 
 I agree with 
 I did n't mean for ESNI to only apply to NameType 0 . There are 256 values , 0 is hostname , 1 can be encryptedservername , and there are 254 more values for additional types of server name types . Going forward I doubt someone will define a plain text type that will have to be protected . But even if that happens encryptedserver_name can encapsulate all name types but itself . P.S. : Not really sure how the use of DNS is a factor here . 
 Recall that SNI extensibility is . 
 Fair enough .
Paragraph (version A):
A "HpkeKeyConfig" structure carrying the configuration information
associated with the HPKE public key.  Note that this structure
contains the "config_id" field, which applies to the entire
ECHConfigContents.  Sites MUST NOT publish two different
"ECHConfigContents" values with the same "HpkeKeyConfig" value.
The RECOMMENDED technique for choosing "config_id" is to choose a
random byte.  This process is repeated if this config_id matches
that of any valid ECHConfig, which could include any ECHConfig
that has been recently removed from active use.
Paragraph (version B):
A "HpkeKeyConfig" structure carrying the configuration information
associated with the HPKE public key.  Note that this structure
contains the "config_id" field, which applies to the entire
ECHConfigContents.
Paragraph (version A):
A one-byte identifier for the given HPKE key configuration.  This
is used by clients to indicate the key used for ClientHello
encryption.
Paragraph (version B):
A one-byte identifier for the given HPKE key configuration.  This
is used by clients to indicate the key used for ClientHello
encryption. config-ids describes how client-facing servers
allocate this value.
Paragraph (version B):
A client-facing server has a set of known ECHConfig values, with
corresponding private keys.  This set SHOULD contain the currently
published values, as well as previous values that may still be in
use, since clients may cache DNS records up to a TTL or longer.
Paragraph (version B):
client-facing-server describes a trial decryption process for
decrypting the ClientHello.  This can impact performance when the
client-facing server maintains many known ECHConfig values.  To avoid
this, the client-facing server SHOULD allocate distinct "config_id"
values for each ECHConfig in its known set.  The RECOMMENDED strategy
is via rejection sampling, i.e., to randomly select "config_id"
repeatedly until it does not match any known ECHConfig.
Paragraph (version B):
It is not necessary for "config_id" values across different client-
facing servers to be distinct.  A backend server may be hosted behind
two different client-facing servers with colliding "config_id" values
without any performance impact.  Values may also be reused if the
previous ECHConfig is no longer in the known set.