Draft: draft-ietf-tls-esni

Commentary: Subsumes and . 
 lgtm 
 What the ... So all already working eSNI in Cloudflare is already outdated ? Do you understand how difficult it will be to get new IN ESNI in Bind and  and even in dig utility ? Do you understand that while IN txt is working in all OS , IN ESNI will not work in any of them ( system resolver , I mean ) ? Do you understand that you use for ESNI RR 0xff9f ( which is ) , so it is reserved for private use in IANA ? Solution for this . Can you please use both of them ? 
 this is good for wiretapping for easy to drop all ESNI with DPI for SNI downgrade 
 PR from implements the ESNI RRType , but there does n't seem to be another issue currently open to track discussion of it . a new RRType allows the removal of the _ esni prefix ( and ) reusing TXT has the potential for conflicts with other uses even with the prefix . ( imagine the definition of a TXT record that simply applied to all DNS entries ) while both TXT and ESNI are 8 bit clean , some people are surprised to learn that about TXT so using a new type may be more robust . Some generic tools processing TXT records would benefit from this . TXT is a set of < = 255 byte strings , defining a new type removes that complexity and reduces overhead There was initially concern about the viability of new RRTypes , but I believe people are more comfortable with that now than when the text was drafted . 
 Fixed in . 
 issue briefly discussed the choice of a esni DNS prefix for the TXT record . I think we should revisit that . My primary concern is that using 2 different names for the addressing and key information makes DNS aliasing un - necessarily complicated . Consider the case where is a customer of and is deploying ESNI for all its customers . A classic way to do this is to have be a CNAME for unfortunately to use 's new ESNI infrastructure would need to add a CNAME record for as well . So the ESNI deployment requires DNS changes outside of the org deploying ESNI , which is going to limit its deployment , which in turn is going to limit the breadth of its anonymity pool . :( Additionally , I 've been told that anecdotally putting names under a CNAME is legal but error prone . RFC 1912 seems to have some language that suggests its not even legal ( though that is informational ) . If the ESNI information were instead stored without a prefix then the alias would automatically apply as the CNAME applies to all the RR 's of a hostname . Part of the reason for choosing the prefix was to avoid collisions in the TXT space , so it makes sense to also reopen and use a non TXT RR type if we drop the prefix . I think the consensus is moving towards that being fine . This would also to harmonize esni with existing dns deployments . 
 I forgot to acknowledge the downside here is with apex records . You ca n't cname an apex record , so the normally annoying second cname with the prefix is actually the only thing the apex can use natively as an alias and this proposal gives that up . otoh apex records inline someone 's A records ( usually a single provider 's anycast ) already so they can do the same thing with esni .. and/or we could allow some kind of delegation explicitly as part of the new rrtype ( i.e. delegation within the new rrtype data , not via cname ) 
 also see pr 
 I am not sure if I agree with the problem statement . To me it seems that the argument is based on the assumption that is the one to decide if ESNI should be applied for I am not sure if all of us would be happy with that assumption . The alternative approach here is to give the owner of each hostname the freedom of deciding whether the hostname should be covered by ESNI . Current design allows the hosting companies to adopt that model , by using the DNS configuration that the hostname owner controls as the switch . 
 ESNI is already a property of the server not the origin name .. in the same way the version of TLS or the cipher suite set is a property of the server .. or the level of http . All necessarily under the control of because it reflects whatever is available on their infrastructure . bighoster may commonly allow their customers to configure this stuff on a per customer or service basis , but that 's a bit of a different take and not incompatible with the approach here . 
 While that might be true , I am not sure if removing the prefix and introducing  ( ) is worth the additional complexity and overhead . Assuming that we merge , becomes a non - issue . Because a wildcard will much all names with the designated type , including the prefix . For example , the following configuration will support ESNI for all the hostnames under , like , , because any query for resolves to . So the only downside is that using prefix and a dedicated RR type at the same time might look strange . But it 's practical . I am not sure if we would prefer to require alias resolution for every ESNI client . Implementation wise , it 's about reimplementing what DNS recursor usually does in the stub resolver . You need to do things like detecting too many redirects and/or loops . There would also be a performance degradation , because each client needs to do the recursive lookup , while with the prefix we can rely on the recursive resolvers to do it and cache it for other clients . To reiterate , I wonder if there is any practical reason to reinvent the wheel . 
 Stretching the bounds of my DNS knowledge here , but I think this makes divergence between the A / AAAA and ESNIKeys records much less likely . That is , when is served by both CDN A and CDN B , the DNS will return or . If both things are record types on the same hostname , then the divergence only happens when the queries happen on opposite sides of a cached CNAME record expiring and getting the opposite answer the next time around . But if they 're separate hostnames , as in the current doc , it 's entirely possible to get opposite CNAME records cached , and you 've diverged for all clients of the caching resolver for the TTL of the shorter CNAME record . That 's a far worse probability of divergence . 
 Fixed in . Closing . 
 if you dynamically syntehsize a whole bunch of names in you would probably use a a / aaaa configuration to do so and give them all the same addresses . but you ca n't do the same things for TXT records with the esni prefix .. basically does n't do the trick ( rfc 4592 ) . initially I viewed this as a configuration and implementation issue because queries and responses do not carry the * at all - the records are synthesized on demand from this config . however , the wildcard is part of AXFR which forms an open interface between resolvers so its syntax and meaning is quite reasonably standardized and should be considered . 
 Minor point but I am not sure if AXFR is something that is exposed to the resolvers . My understanding is standardized interface for synchronizing authoritative servers . So this will be an issue only for websites that use a DNS that either depends on AXFR ( or in other ways depend on the vocabulary of the AXFR ) . I agree that it would be preferable to address the issue . 
 my thought here is that axfr represents an interface between , potentially , different implementations so we should try and respect that to whatever extent is possible . 
 My view of the issue is that we can support all the models that we need to support if we adopt so that ESNIKeys will be distributed using a dedicated type with a prefix . The patterns we need to consider are the combination of three types of DNS records ( i.e. single - host , APEX , wildcard ) and a boolean indicating if DNS is maintained by someone other than the CDN . The table below illustrates how you could configure the DNS on each case . There are certain cases in which you could use CNAME instead of A / ESNI . 1 : You will be required to create _ esni records for all hosts that you specify explicitly , if it is necessary to disable ESNI for those hosts ( or if those hosts use different ESNI keys ) . 
 Fixed in . 
 dns records are 8 bit clean and rfc 6763 is an example of a TXT record carrying arbitrary data 
 : +1 : Base64 is not only complication . It is a space overhead for a large object like ESNIKeys . Seeing corruption of binary will be rare ; we can detect them by validating the checksum and fallback to non - ESNI in such case . So why not go for binary ? FWIW ,  was introduced in . 
 This is solved in which removes base64 with new ESNI RR type . 
 We only this since TXT records were claimed to not work well with binary , per Christian ’s suggestion . I ’m fine either way . 
 Thanks for the info . I found , in which asks : We know that we can store more than 128 octets in TXT record , and that we have a precedent that uses TXT to store binary data , as has pointed out . Regarding configurability , my understanding is that RFC 1035 defines how binary TXT records can be specified in a zone file , and therefore many DNS server " softwares " support having such records . Googling also tells me that managed DNS services like Route 53 and Azure DNS provide the capability , although surprisingly they use different escape sequences ( uses + 3 octal , uses + 3 decimal ) . 
 I do not think it ’s a complication , and I ’m not convinced space is an issue as per your comment above . 
 only tangentially related - do you know why your txt record is broken into 127 char strings instead of 255 ? Is there a bug being worked around somewhere ? 
 Oh I did not notice that . I am using tinydns ( of djbdns ) , and it seems like tinydns works that way ( see ) . 
 The issue about the size is that with  we might hit the 512 - octet threshold when publishing keys of multiple strengths . As an example , query for currently returns a 186 - byte response , which contains just secp256r1 key . If we add secp384r1 and secp521r1 , I 'd assume that the size will come near to 490 octets . In other words , for longer hostnames we will hit the 512 - octet threshold if we publish three keys . If we avoid the  encoding , we will have enough room to store 3 ECDH keys that can provide 128- , 192- , 256 - bit - level security . I do not think this argument is strong enough to prohibit the use of base64 for the following reasons : we will be using DoH / DNS over TLS between the client and the resolver we might be using DNS over UDP that has the 512 - octet threshold between the resolver and the authoritative server , but we would want that to migrate to DNSSEC or something even better we might be just fine with publishing only two keys : X25519 , X448 But it does make me prefer not to have the overhead of  , if that is possible . 
 Fixed in . 
 : +1 :
Paragraph (version A):
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.  Servers MAY supply multiple
ESNIKeys values, either of the same or of different versions.  This
allows a server to support multiple versions at once.  If the server
does not supply any ESNIKeys values with a version known to the
client, then the client MUST behave as if no ESNIKeys were found.
Paragraph (version A):
Servers MUST ensure that if multiple A or AAAA records are returned
for a domain with ESNI support, all the servers pointed to by those
records are able to handle the keys returned as part of a ESNI TXT
record for that domain.
Paragraph (version B):
This structure is placed in the RRData section of an ESNI record as-
is.  Servers MAY supply multiple ESNIKeys values, either of the same
or of different versions.  This allows a server to support multiple
versions at once.  If the server does not supply any ESNIKeys values
with a version known to the client, then the client MUST behave as if
no ESNIKeys were found.
Paragraph (version B):
Servers MUST ensure that if multiple A or AAAA records are returned
for a domain with ESNI support, all the servers pointed to by those
records are able to handle the keys returned as part of an ESNI
record for that domain.
Paragraph (version A):
In cases where the domain of the A or AAAA records being resolved do
not match the SNI Server Name, such as when RFC7838 is being used,
the SNI domain should be used for querying the ESNI TXT record.
Paragraph (version B):
In cases where the domain of the A or AAAA records being resolved do
not match the SNI Server Name, such as when RFC7838 is being used,
the SNI domain should be used for querying the ESNI record.
Paragraph (version A):
In order to send an encrypted SNI, the client MUST first select one
of the server ESNIKeyShareEntry values and generate an (EC)DHE share
in the matching group.  This share will then be sent to the server in
the "encrypted_sni" extension and used to derive the SNI encryption
key.  It does not affect the (EC)DHE shared secret used in the TLS
key schedule.  It MUST also select an appropriate cipher suite from
the list of suites offered by the server.  If the client is unable to
select an appropriate group or suite it SHOULD ignore that ESNIKeys
value and MAY attempt to use another value provided by the server
(recall that servers might provide multiple ESNIKeys in response to a
ESNI TXT query).  The client MUST NOT send encrypted SNI using groups
or cipher suites not advertised by the server.
Paragraph (version B):
In order to send an encrypted SNI, the client MUST first select one
of the server ESNIKeyShareEntry values and generate an (EC)DHE share
in the matching group.  This share will then be sent to the server in
the "encrypted_sni" extension and used to derive the SNI encryption
key.  It does not affect the (EC)DHE shared secret used in the TLS
key schedule.  It MUST also select an appropriate cipher suite from
the list of suites offered by the server.  If the client is unable to
select an appropriate group or suite it SHOULD ignore that ESNIKeys
value and MAY attempt to use another value provided by the server.
(Recall that servers might provide multiple ESNIKeys in response to a
ESNI record query.)  The client MUST NOT send encrypted SNI using
groups or cipher suites not advertised by the server.