Original text:
SNI Encryption keys can be published in the DNS using the ESNIKeys structure, defined below. <del> An opaque label used to identify the list of keys. </del> 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. The encrypted SNI is carried in an "encrypted_server_name" extension, which contains an EncryptedSNI structure: <del> The label associated with the SNI encryption key. A cryptographic hash of the ESNIKeys structure from which the label and ESNI key was obtained, i.e., from "checksum" to the end of the structure.  This hash is computed using the hash function </del>  associated with "suite". The cipher suite used to encrypt the SNI. If it is unable to negotiate TLS 1.3 or greater, it MUST abort the connection with a "handshake_failure" alert. <del> If the EncryptedSNI.label value does not correspond to any known SNI encryption key, it MUST abort the connection with an "illegal_parameter" alert.  [[OPEN ISSUE: We looked at ignoring the extension but concluded this was better.]] </del> If the EncryptedSNI.record_digest value does not match the <del> cryptographic hash of the associated ENSIKeys structure, it MUST abort the connection with an "illegal_parameter" alert.  This is necessary to prevent downgrade attacks. </del>  If more than one KeyShareEntry has been provided, or if that share's group does not match that for the SNI encryption key, it key is provided, sharing is optimally bound by the number of hosts that share an IP address.  Server operators may further limit sharing by sending different Resource Records containing ESNIKeys with <del> different keys covered by different labels using a short TTL. </del>  7.2.3. This design requires servers to decrypt ClientHello messages with <del> EncryptedSNI extensions carrying valid labels.  Thus, it is possible </del>  for an attacker to force decryption operations on the server.  This attack is bound by the number of valid TCP connections an attacker can open. 7.2.4. <del> By sending SNI and ESNI values (with illegitimate labels), or by </del>  sending legitimate ESNI values for and "fake" SNI values, clients do not display clear signals of ESNI intent to passive eavesdroppers. As more clients enable ESNI support, e.g., as normal part of Web

Reviewer comments:
Now that has been merged, label seems to be an unnecessary complication. label has no actual use on the client because labels cannot collide, the key generator needs to either keep some state across all invocations (you need a trustable store), or generate a UUID (it's just a random junk) to be used as a label a TLS server is required to at first compare the label and then check the digest. These three issues go away if we eliminate label. Key generators do not need to care about uniqueness. TLS servers can just look for the matching digest and that's it. Note that a server operator can still associate an identifier to the ESNIKeys structure for internal use. The private key will be kept in relation to the structure anyways. So having a private identifier does not complicate things at all.
After very useful discussion with many folks, it seems now is the time to remove config_id. There are a couple reasons to do this: Servers need to know the correct hash function to use when computing the ID, and possibly need to compute multiple IDs for a given public key (since a config can have multiple hash-based KDFs), which is somewhat annoying and redundant. The entire ECHConfig is already authenticated, so using a hash to prove that the client made a determination based on the correct config contents is unnecessary. Servers will likely only ever have a small handful of keys in motion at any point in time, so anything more than a couple of bits to identify one of said keys is excessive. ... there are probably more. The original design . (Oops!) It seems we're now in a better position to bring this back, but with some simplifications.
Hiya, Can you send a pointer to those discussions? (Sorry, I seem to have missed 'em;-) Ta, S.
Sorry -- these were informal conversations off-list.
Ah. That's a recurring problem. And even this exchange is actually off-list. Can we please fix that? I think I've whined about that a few times now, and would hope that continual whining is not a requirement;-) S.
few times now, and would hope that continual whining is not a requirement;-) Fix what? A few of us had a private conversation about some ideas and came to the conclusion that it would be better to replace the hash with a key_id. Then Chris and Martin brought it to a Github issue. This is precisely in line with the WG consensus to use Github issue discussion mode, as documented in 8874 S 5.3.
I'm guessing that was a private discussion amongst what could well be described as the usual suspects or an old-boys club (or are a few of you "many folks?"). Correct me if I'm wrong but that had zero visibility and zero traceability and zero accountability for anyone who isn't one of those old boys. And yet we're zapping a field in a PDU from what was declared as an "implementation draft" a day or so after one major deployment declared they had an interop target. To me, that smells of disrespect for outsiders tbh. You can probably guess what I think about that state of affairs:-) I don't buy that tbh. Chris' mail was presented as a conclusion, from a wg-chair following a private discussion that for sure excluded some implementers. (Me being one, albeit a not very good one:-) And you yourself are an ex WG-chair so I'd guess you ought also care about exclusivity here. What gain is there from that kind of behaviour? I don't see it myself. IMO, there is no need nor benefit from being so exclusive wrt this spec, yet that is what is happening and has been for a few years. I'd encourage those of you who may be "old-boys" to consider whether or not that is really the best way to proceed. IMO - it is not, you lose way more than you might think you gain, almost all the time. Cheers, S. PS: I don't disagree with the outcome, though have opinions on what -10 might contain. I do very much dislike the awful process, which is my point here.
NAME I would completely agree with you had the proposed PR been merged and the associated issue been closed. That has not happened. Further, it appears that you might be reading a bit more into Chris' issue summary than is really there. He is not acting in his WG chair capacity here because he is an author; I know he knows that and I really hope you can give him the benefit of the doubt here so that we do not have to suffer the "no WG chair hat on" in every message/post. The process, as I see it, is pretty darn near normal. Somebody files an issue and optionally (but preferably) files a PR to address said issue. Discussion ensues amd if substantive it's taken to the list. The PR may or may not be modified based on that discussion. If consensus is reached, the PR is merged and the issue is closed. We are at the discussion point. Can we do that now?
Perhaps it'd be better to not start a mail with "After very useful discussion with many folks, it seems now is the time to remove config_id." in cases where that discussion was purely private? I can understand it being hard to keep track with the various tools, but for me, that still reads as a decision being announced even if that was not the intent. Sorry for being over-sensitive to this but IMO there is a history and ongoing tendency with this spec for a subset of people to act as if they and not the IETF/WG have change control. I fully accept that they are not deliberately aiming to avoid having to garner WG consensus but consider that ongoing instances of carelessness such as the above demonstrate that there is an insider/outsider thing going on here. S.
The text in section 4, Publishing the SNI Encryption Key, specifies that if a client queries URL, the ESNI TXT name is URL That's fine, but suppose that the client queries "URL". The client needs to learn that "URL" is fronted by "URL" -- per PR , the client will do that by obtaining an ALT-SVC record. Should the client get the ESNI key from "URL", or from "URL" ?
NAME I think this is you.
covers this. Mostly. It might pay to observe that the client does not look up and DNS records for the fronting service, it is just the case that all servers in the anonymity set point to the same IP address. I made similar comments on .
I agree with NAME here. I didn't see the client querying URL
That means all servers that share the same IP need to publish the same key. Are we confident that there is no synch issue during key rollover?
Servers can publish multiple ESNI keys with different labels in a record. That way they can retire one key and start using another as needed. Though it might be good (necessary?) to require clients to use one of those keys.
While that is possible, I am not sure if it would be the approach that would generally be used. The issue is identical to the encryption key of the session tickets. In case of session tickets, we encrypt the ticket using one key, and send the identifier of the key along with the encrypted ticket. When we rollover the keys, we first deploy a new key to the server as well as keeping the old one alive for decryption only. And we retire the old key after certain amount of period that we become sure that it is no longer used. I'd assume that we can and will use the same approach for ESNIKeys.
PS. therefore, it is possible to have just one label for the set of keys rather than having labels for each of the keys (assuming that we can remove the "choose one at random" rule). In that approach, a server will identify the key being used by looking at the tuple. The benefit will be that you will save the space of N-1 labels assuming that you are sending N key shares. Identification of the key on the server-side might seem complicated, but I actually think that it simplifies things, because a server operator is anyways expected to deploy the entire set of keys found in ESNIKeys at the same moment.
To me it seems that this is necessary to prevent downgrade attack. Hence .
How do we prevent labels from becoming identifiers?
Labels as identifiers seem problematic in both approaches -- current and .
Would you mind elaborating why label becomes an identifier? We state in the document that the probability of identifying the hidden server is 1/N where N is the number of the hosts belonging to the same set of hidden servers. A label represents that entire set. So I do not think it is an issue.
Now that is merged, which removes the label altogether, and we've added text describing the anonymity set for hidden servers, I think this issue is covered. NAME do you agree?
The label issue is definitely covered.
LGMT -- I much prefer content-based identifiers to labels.

Revised text:
SNI Encryption keys can be published in the DNS using the ESNIKeys structure, defined below.  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. The encrypted SNI is carried in an "encrypted_server_name" extension, which contains an EncryptedSNI structure:  <ins> A cryptographic hash of the ESNIKeys structure from which the ESNI key was obtained, i.e., from "checksum" to the end of the structure.  This hash is computed using the hash function </ins> associated with "suite". The cipher suite used to encrypt the SNI. If it is unable to negotiate TLS 1.3 or greater, it MUST abort the connection with a "handshake_failure" alert.  If the EncryptedSNI.record_digest value does not match the  <ins> cryptographic hash of any known ENSIKeys structure, it MUST abort the connection with an "illegal_parameter" alert.  This is necessary to prevent downgrade attacks.  [[OPEN ISSUE: We looked at ignoring the extension but concluded this was better.]] </ins> If more than one KeyShareEntry has been provided, or if that share's group does not match that for the SNI encryption key, it key is provided, sharing is optimally bound by the number of hosts that share an IP address.  Server operators may further limit sharing by sending different Resource Records containing ESNIKeys with  <ins> different keys using a short TTL. </ins> 7.2.3. This design requires servers to decrypt ClientHello messages with  <ins> EncryptedSNI extensions carrying valid digests.  Thus, it is possible </ins> for an attacker to force decryption operations on the server.  This attack is bound by the number of valid TCP connections an attacker can open. 7.2.4.  <ins> By sending SNI and ESNI values (with illegitimate digests), or by </ins> sending legitimate ESNI values for and "fake" SNI values, clients do not display clear signals of ESNI intent to passive eavesdroppers. As more clients enable ESNI support, e.g., as normal part of Web