Change:
A one-byte identifier for the given HPKE key configuration.  This is used by clients to indicate the key used for ClientHello <del> encryption. </del> <ins> encryption. config-ids describes how client-facing servers allocate this value. </ins> The HPKE KEM identifier corresponding to "public_key".  Clients MUST ignore any "ECHConfig" structure with a key using a KEM they

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