Change:
4.1. <ins> 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. 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. 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. 4.2. </ins> ECH configuration extensions are used to provide room for additional functionality as needed.  See config-extensions-guidance for guidance on which types of extensions are appropriate for this structure.

Discussion:
NAME 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 don'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.
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 NAME
I didn'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. The Server Name Indication (SNI) extension in TLS has a provision to provide names other than host names[1]. None have even been defined to my knowledge, but it's there. OpenSSL (and possibly others) have had a long-standing bug[2] (fixed in master) that means that different types of names will cause an error. To be clear: I live in a glass house and am not throwing stones; these things happen. However, it means that a huge fraction of the TLS deployment will not be able to accept a different name type should one ever be defined. (This issue might have been caused by the fact that the original[3] spec didn't define the extension in such a way that unknown name types could be skipped over.) Therefore we (i.e. BoringSSL, and thus Google) are proposing to give up on this and implement our parser such that the SNI extension is only allowed to contain a single host name value. (This is compatible with all known clients.) We're assuming that since this is already the de-facto reality that there will be little objection. I'm sending this mostly to record the fact so that, if someone tries to define a new name type in the future, they won't waste their time. If the community wishes to indicate a different type of name in the future, a new extension can be defined. This is already effectively the case because we wouldn't fight this level of incompatibility when there's any other option. (I think the lesson here is that protocols should have a single joint, and that it should be kept well oiled. For TLS, that means that extensions should have minimal extensionality in themselves and that we should generally rely on the main extensions mechanism for these sorts of things.) [1] URL [2] URL – note that the data pointer is not updated. [3] URL Cheers AGL Adam Langley EMAIL URL