Original text:
An (EC)DH key share (attached to the label)  The list of keys which can be used by the client to encrypt the SNI. names it supports, and will not work if the mapping between the fronting server and the hidden server uses wildcards.]]  A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in I-D.ietf-tls-tls13; Section 4.2.  The purpose of the field is to probability may be increased via traffic analysis or other mechanisms. <del> The Resource Record TTL determines the lifetime of the published ESNI keys.  Clients MUST NOT use ESNI keys beyond their published lifetime.  Note that the length of this structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035. </del>  5.

Reviewer comments:
I expect that the resistance against ESNIKeys will come from web-site owners worrying about ESNIKeys being additional source of service disruption. One might argue that the probability of disruption becomes 2x because now two resource records (A and esni) are involved instead of just one. One might argue that the probability is higher than that because there could be more issues with carrying large TXT records than carrying A records. One might argue that the probability is below 2x because the two records are transmitted through the same path. Anyways, these arguments are about the quantitative difference about the probability. I prefer having a qualitative guarantee, that assures that there would be no increase in the probability of service disruption assuming that the owner of the record does not misconfigure the service. Having a checksum and validity period fields that can be validated by the client provides such guarantee. Checksum provides protection against accidental corruption. Validity period provides protection against misconfiguration or bugs in the DNS servers. It acts as a protection against an outdated ESNIKeys sent by an out-of-sync authoritative server or a buggy resolver causing disruption. The downside of having checksum and validity is that the additional payload (currently 20 bytes, I think we can minimize this to 10 bytes by removing (it's not that needed) and changing the type of from to ), and that the client would be required to do the validation. But I assume that having qualitative guarantee that the probability of service disruption remains the same is worth the effort.
NAME The PR is now aligned with master. I think we should merge this and rebase upon this regardless of what we end up with on the PR.
Does the advertisement really need a checksum? It complicates things for questionable benefit. Use DNS-over-something-that-isn't-as-lame-as-UDP and this problem goes away. You probably want DNS to be protected by TLS anyway.
As discussed on URL and URL, I prefer to have the checksum for end-to-end integrity checking and to not have increased risk of service disruption for better adoption of ESNI; otherwise the hosts that using ESNI would stick out. It's not only when transmitting data over the wire that the ESNIKeys might get corrupt. That could happen before the record gets installed on the authoritative server, or while the data is being cached in a resolver. Or we might have other conveyer in the future.
Yeah, I don't find those arguments particularly persuasive. The biggest risk is misconfiguration, which - given the nature of this - won't be persistent. Sites that do this will test their code and once it is fixed, it should work. As for network-level corruption, that's rare, and DNS over TLS (or DoH) aren't really vulnerable to that.
I agree that corruption is rare; the question is if it is as rare as TCP transferring corrupt data. I would like to also point out that corruption cannot be immediately fixed; you need to wait for the cached records to expire. And even if you use DNS over TLS or DOH between the client and the resolver, you could still be using unauthenticated DNS over UDP between the resolver and the authoritative server.
NAME NAME shall we consider this issue resolved?
Considering resolved.
Doing so doesn't allow a server to gracefully generate new ESNI keys and retire old ones. We should mandate that clients always choose the first ESNI key for which they have group support. If we adopt , where servers lookup keys with a (label, group) -> key mapping, should we also require that each label have the same groups?
NAME what do you think?
I am not sure what you mean by "doing so", but the model I expect is something like following assuming that we adopt . the fronting server generates a new ESNIKeys and pushes it to DNS server every 1 hour TTL will be set to 5 minutes 1 the fronting server will accept the following keys to be used in the EncryptedSNI extension: the key for the current hour the key for the previous hour, for the first 10 minutes of every hour A ESNIKeys record can contain multiple keys belonging to different groups, but not belonging to the same group. So there is no ambiguity by specifying the key using (label, group). The server can add a new Named Group or retire one when it generates a new ESNIKeys. [1] updated to reflect the fact that we can only use a constant TTL in the standard way of DNS server synchronization (i.e. DNS zone transfer) (02:47UTC May 15 2018)
That seems perfectly fine. But it does mean that there exists only one key per group at any given point in time. Is that a restriction we are comfortable with?
I don't think so. A DNS server can send different ESNIKeys at the same hour using short TTL (e.g. 60 seconds) in response to different queries (a.k.a. round-robin DNS).
Sorry, I mean within a single record.
I am comfortable with not having that. You can only have a handful of keys in ESNIKeys anyways. I'd assume that either one would be enough or we would need a way to distribute more than just a handful, for which we can use round-robin.
SGTM. We should add this rationale as text to the DNS record section.
I think that TTL suffices here.
NAME FWIW, is now in master. We can certainly discuss about the necessity, but you might want to see the debate on .
NAME I think your point in the PR is quite valid. However it's probably worth noting that having explicit notbefore / notafter that the client has to validate, is likely to make it very difficult, if not impossible, to deploy very-short-lived keys (say, in the order of a few hours), due to the fact that a significant portion of clients have shitty clocks (URL), which affects forward secrecy. Maybe it should be noted in the spec as an appendix or something.
Hmmm, thinking about this some more. In the "split brain" case NAME described in , the not_after is used to avoid having clients send an ESNI encrypted with an old key (as fetched from an out-of-date DNS server), to a TLS server that might have already switched to a new key (thus causing the connection to break). So i'm guessing what happens is that the client would fallback to plaintext SNI if the key it fetched from DNS is expired. Though it seems to me this fallback could be dangerous for the client since they would end up exposing the SNI, but I can't come up with a practical way to exploit this (could be dependent on the specific deployment I guess). Whether this is something worth fixing is a different question, but an alternative to fix the split brain problem would be for the TLS server to somehow make sure the new key has been received by the DNS server, before discarding the old one. Did I understand the problem you described in correctly NAME ?
NAME Thank you for your comments. I think you are correct in stating that the ESNIKeys cannot have a very short lifetime. However, I would like to argue that the fact does not prevent server operators from rotating the keys frequently. Server operators can rotate the keys at the speed they like, as well as retiring them from the servers in any way. I agree with what happens. In my view, ESNI is opportunistic encryption in sense that the unencrypted hostname is used when the ESNI resource record fails to reach the client (including the case of a middlebox dropping it intentionally). I would argue that using SNI in case of receiving an expired ESNI record is one of the failure modes in distributing the correct resource record. And therefore, I do not think that it is a security concern. That is correct. However, I fear that having such a requirement hinders us from using existing DNS deployments, because DNS authoritative servers are designed to favor availability over consistency, whereas in our case without , we need consistency over availability.
I didn't realize that was possible (that is, I kind of assumed servers would have to keep the key around until the notafter expired, but it's not actually written anywhere). In that case fine, though it might be worth clarifying. The other concern I had was risking of turning this into another OCSP (where network failure and attack basically look the same so clients end up ignoring both), but I guess that with DoH, DPRIVE and DNSSEC an attack here is much harder to pull off. So all in all I don't have a strong opinion on notbefore / not_after anymore.
I think this is fine, NAME please re-open if not.
The biggest concern from web-site operators will be the possibility of out-of-sync or broken ESNIKeys leading to service disruption. Considering that, I propose having two attributes being added: validity - we can borrow and from PKIX checksum - something like 32-bits would be enough Seeing wired ESNIKeys will become a big issue especially if the clients accept ESNIKeys sent from low-quality resolvers / proxies (e.g. those in home routers). PS. One alternative approach would be to use HTTP (.well-known URI) as a transport of the semi-static key between the TLS server and the resolver. Then, we can use the vocabulary of HTTP to implement client-side verification.

Revised text:
An (EC)DH key share (attached to the label) <ins> 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. </ins> The list of keys which can be used by the client to encrypt the SNI. names it supports, and will not work if the mapping between the fronting server and the hidden server uses wildcards.]] <ins> The moment when the keys become valid for use.  The value is represented as seconds from 00:00:00 UTC on Jan 1 1970, not including leap seconds. The moment when the keys become invalid.  Uses the same unit as not_before. </ins> A list of extensions that the client can take into consideration when generating a Client Hello message.  The format is defined in I-D.ietf-tls-tls13; Section 4.2.  The purpose of the field is to probability may be increased via traffic analysis or other mechanisms.  <ins> The "checksum" field provides protection against transmission errors, including those caused by intermediaries such as a DNS proxy running on a home router.  "not_before" and "not_after" fields represent the validity period of the published ESNI keys.  Clients MUST NOT use ESNI keys that was covered by an invalid checksum or beyond the published period.  Servers SHOULD set the Resource Record TTL small enough so that the record gets discarded by the cache before the ESNI keys reach the end of their validity period. Note that the length of this structure MUST NOT exceed 2^16 - 1, as the RDLENGTH is only 16 bits RFC1035. </ins> 5.