mcmanus
commented
5 years ago This has been kicked around before and generally not selected based on the downsides you identify - prinicipally the serialization issue as well as practical matters of control of PTR records. It also prohibits the use of more than 1 key on an address - that's obviously a bad thing for the anonymity pool at its extreme, but some architectures might require more than one pool.
You can fix the latter two issues by using another suggestion that has previously been made: connect to the server and validate an IP based certificate and then get the ESNI key via a REST API (or equivalent) - but that is still likely too slow and comes with the challenges of IP based certificate management.
On Fri, Mar 1, 2019 at 1:35 PM jb-wisemo notifications@github.com wrote:
To maximize the cover range for clients and simplify management of the ESNI records, it is more useful to associate the ESNI records with the server rather than the query domain name. This has the additional benefit of allowing different client-facing servers to use different rotating private DH keys.
This eliminates the issues with CNAMEs, individual query domain holders having to make changes, DNS namespace issues etc.
For example a large hoster wishing to provide cover for some clients by having their primary / CDN front ends offer ESNI for all requests can then simply enable the code on their server then add the ESNI records. They can even do this gradually over a large pool of servers, thus having some servers with different (or no) ESNI support during each careful rollout of ESNI software upgrades.
In practice the following conventions would be used:
-
Any ESNI server IP must have exactly one PTR record (typically pointing to the hoster domain, such as a typical systematic CDN node DNS name). Lets call this name ptrnam.dom
The ESNI records would be under _esni.ptrnam.dom
As with most PTR records ptrnam.dom is expected to have exactly one AAAA or A record pointing back at the same IP (if the starting IP is IPv6 only AAAA need to satisfy this, if IPv4 only A, the same ptrnam.dom can be used for one IPv4 and one IPv6 address if the ESNI records would be the same).
- For address-less server types such as tor hidden services, the ESNI records would be published via whatever DNS or DNS-like mechanism is used for that transport, or queried by sending a DNS query for the record to the target, allowing the target to respond within that transport.
Benefits:
-
B1. Large client-facing servers such as CDNs and shared IP hosters can deploy ESNI without having to negotiate DNS changes with all their customers (in fact with any of their customers).
B2. Operators of large pools of client-facing servers such as CDNs can roll out ESNI support and ESNI implementation upgrades in a piecemeal and controlled manner similar to how other system updates are rolled out. Simply because each IP address will have its own ESNI records.
B3. ESNI key rotation becomes much simpler as there is no need to synchronize it between different servers in a pool (except where a pure layer 1/2/3 load balancer shares a single IP among multiple physical/virtual servers, such as the layer 2 HALinux scheme).
B4. ESNI private key protection can be much stronger when it is not shared among all the servers. The private key may be kept in protected hardware and/or in volatile RAM. The latter case would require clients to fall back to a different A or AAAA record until the DNS entries for now forgotten keys to have expired, but only in case of a server crash or similar event.
B5. Client queries for ESNI records do not reveal the actual query domain that will be encrypted, only the IP address to which the ESNI extension will be sent.
B6. The whole discussion about _esni prefix or no _esni prefix becomes a lot simpler when there is no need to put ESNI records in every end query domain, only domains of the client-facing servers, allowing to keep the unprefixed TXT name space clean for existing uses such as SPF.
Downsides:
-
P1: Clients will have to postpone the _esni DNS query until after receiving the answer to the A or AAAA query, thus adding an extra DNS roundtrip before the first connection to a name. The usual DNS caching hierarchy should mitigate this. In particular for popular CDNs, a client will typically use the same handful of IPs for lots of unrelated traffic, thus getting the ESNI records in its local cache.
P2: VM hosting/Physical hosting/connectivity providers not granting PTR name assignment control to IP address customers will cause the same problems as for other protocols (such as mail) and should thus be under the same or greater pressure to add that service. However since the greatest ESNI benefit is with IPs shared among many unrelated domains, and the operators of such IPs typically have full IP space ownership or the leverage to get PTR records where normal customers cannnot, the effect on ESNI deployment should be limited.
P3: This may or may not make it easier to do spoofing attacks, as an MitM attacker can spoof DNS responses either for the A/AAAA records of a target query domain (pointing to servers entirely under the attackers control, including legitimate ESNI records for that server) OR spoof the ESNI records of a server address for which the attacker has obtained traffic intercept ability. However these can be secured with the same DNS countermeasures already applicable to those DNS domains.
P4: query domains wishing to remain available in massively blocking markets (the kind that would not hesitate to block an entire CDN to stop access to a single web page) may have more difficulty opting out of ESNI so such blocking filters can recognize them as a permitted service.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/tlswg/draft-ietf-tls-esni/issues/139, or mute the thread https://github.com/notifications/unsubscribe-auth/AAP5szSqBkYuhH39f6ZWOFhNfNZdY9dlks5vSXMCgaJpZM4bZlWX .
jb-wisemo
kazuho
ekr
chris-wood
To maximize the cover range for clients and simplify management of the ESNI records, it is more useful to associate the ESNI records with the server rather than the query domain name. This has the additional benefit of allowing different client-facing servers to use different rotating private DH keys.
This eliminates the issues with CNAMEs, individual query domain holders having to make changes, DNS namespace issues etc.
For example a large hoster wishing to provide cover for some clients by having their primary / CDN front ends offer ESNI for all requests can then simply enable the code on their server then add the ESNI records. They can even do this gradually over a large pool of servers, thus having some servers with different (or no) ESNI support during each careful rollout of ESNI software upgrades.
In practice the following conventions would be used:
Any ESNI server IP must have exactly one PTR record (typically pointing to the hoster domain, such as a typical systematic CDN node DNS name). Lets call this name ptrnam.dom
The ESNI records would be under _esni.ptrnam.dom
As with most PTR records ptrnam.dom is expected to have exactly one AAAA or A record pointing back at the same IP (if the starting IP is IPv6 only AAAA need to satisfy this, if IPv4 only A, the same ptrnam.dom can be used for one IPv4 and one IPv6 address if the ESNI records would be the same).
For address-less server types such as tor hidden services, the ESNI records would be published via whatever DNS or DNS-like mechanism is used for that transport, or queried by sending a DNS query for the record to the target, allowing the target to respond within that transport.
Benefits:
B1. Large client-facing servers such as CDNs and shared IP hosters can deploy ESNI without having to negotiate DNS changes with all their customers (in fact with any of their customers).
B2. Operators of large pools of client-facing servers such as CDNs can roll out ESNI support and ESNI implementation upgrades in a piecemeal and controlled manner similar to how other system updates are rolled out. Simply because each IP address will have its own ESNI records.
B3. ESNI key rotation becomes much simpler as there is no need to synchronize it between different servers in a pool (except where a pure layer 1/2/3 load balancer shares a single IP among multiple physical/virtual servers, such as the layer 2 HALinux scheme).
B4. ESNI private key protection can be much stronger when it is not shared among all the servers. The private key may be kept in protected hardware and/or in volatile RAM. The latter case would require clients to fall back to a different A or AAAA record until the DNS entries for now forgotten keys to have expired, but only in case of a server crash or similar event.
B5. Client queries for ESNI records do not reveal the actual query domain that will be encrypted, only the IP address to which the ESNI extension will be sent.
B6. The whole discussion about _esni prefix or no _esni prefix becomes a lot simpler when there is no need to put ESNI records in every end query domain, only domains of the client-facing servers, allowing to keep the unprefixed TXT name space clean for existing uses such as SPF.
Downsides:
P1: Clients will have to postpone the _esni DNS query until after receiving the answer to the A or AAAA query, thus adding an extra DNS roundtrip before the first connection to a name. The usual DNS caching hierarchy should mitigate this. In particular for popular CDNs, a client will typically use the same handful of IPs for lots of unrelated traffic, thus getting the ESNI records in its local cache.
P2: VM hosting/Physical hosting/connectivity providers not granting PTR name assignment control to IP address customers will cause the same problems as for other protocols (such as mail) and should thus be under the same or greater pressure to add that service. However since the greatest ESNI benefit is with IPs shared among many unrelated domains, and the operators of such IPs typically have full IP space ownership or the leverage to get PTR records where normal customers cannnot, the effect on ESNI deployment should be limited.
P3: This may or may not make it easier to do spoofing attacks, as an MitM attacker can spoof DNS responses either for the A/AAAA records of a target query domain (pointing to servers entirely under the attackers control, including legitimate ESNI records for that server) OR spoof the ESNI records of a server address for which the attacker has obtained traffic intercept ability. However these can be secured with the same DNS countermeasures already applicable to those DNS domains.
P4: query domains wishing to remain available in massively blocking markets (the kind that would not hesitate to block an entire CDN to stop access to a single web page) may have more difficulty opting out of ESNI so such blocking filters can recognize them as a permitted service.