Change:
cipher suite list is orthogonal to the list of keys, so each key may be used with any cipher suite. <del> This structure is placed in the RRData section of a TXT record as encoded above.  The name of each TXT record MUST match the name composed of "_esni" and the query domain name.  That is, if a client queries example.com, the ESNI TXT name is _esni.example.com.  Servers SHOULD configure DNS such that, upon querying a domain name with ESNI support, at most one each of A, AAAA, TXT ESNI, and ALTSVC I- D.schwartz-httpbis-dns-alt-svc Resource Record is returned.  Alt-Svc records may be used to inform the client of the plaintext (fronting) SNI.  Also, servers operating in Fronting Mode SHOULD have DNS </del> <ins> This structure is placed in the RRData section of a TXT record as a base64-encoded string.  If this encoding exceeds the 255 octet limit of TXT strings, it must be split across multiple concatenated strings as per Section 3.1.3 of RFC4408. The name of each TXT record MUST match the name composed of _esni and the query domain name.  That is, if a client queries example.com, the ESNI TXT Resource Record might be: Servers SHOULD configure DNS such that, upon querying a domain name with ESNI support, at most one each of A, AAAA, TXT ESNI, and ALTSVC I-D.schwartz-httpbis-dns-alt-svc Resource Record is returned.  Alt- Svc records may be used to inform the client of the plaintext (fronting) SNI.  If present, clients SHOULD use its value in the SNI extension of the subsequent ClientHello. Clients obtain these records by querying DNS for hidden server domains.  Thus, servers operating in Fronting Mode SHOULD have DNS </ins> configured to return the same A (or AAAA) record for all hidden <del> servers they service. </del> <ins> servers they service.  This yields an anonymity set of cardinality equal to the number of hidden server domains supported by a given fronting server.  Thus, even with SNI encryption, an attacker which can enumerate the set of hidden server domains supported by a fronting server can guess the correct SNI with probability at least 1/K, where K is the size of this hidden server anonymity set.  This probability may be increased via traffic analysis or other mechanisms. </ins> The Resource Record TTL determines the lifetime of the published ESNI keys.  Clients MUST NOT use ESNI keys beyond their published

Discussion:
… deal with TXT string limits.
NAME NAME please take a look.
NAME NAME updated based on your feedback -- please take a look!
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.
The proposed DNS publication method for the key is sketched in section 4, Publishing the SNI Encryption Key. The proposed structure is This can be problematic, given the constraints on TXT records. The practical length of the record payload is at most 255 bytes. The payload content is supposed to be text, which would suggest a base64 encoding, further reducing the available payload size to 189 bytes. I would suggest encoding just one key & one ciphersuite per record using base64 encoding, and using multiple records if necessary.
FWIW RFC 4408 allows you to have multiple strings in the same TXT record to get around the limit URL This should probably be one key and all cipher suites, since suites and keys are orthogonal to each other.
We assumed a suitable encoding that would not bump into this bound. Alessandro’s suggestion above seems best.
I really have two concerns, the maximum length and the char requirement. The latter may be an harder issue. For example, can I set a TXT record to contain binary data if I use Amazon's Route 53 service?
I think we can work around the first with the concatenation suggestion. For the second, I assumed (perhaps incorrectly) any binary data was admissible. If we can’t use binary data, then we can encode it easy enough.
NAME Shall we close this?

Closed after merging PR
That's more words than I expected, but they all seem useful. LGTM.The general idea looks good, but I am a bit concerned with the concatenation + reordering process, as in theory servers may return records in random order. On the other hand, RFC 4408 has been out for a long time, so maybe that's not really a problem in practice.