DNS Encryption Protocol

Factual Questions
21

Yes, Mozilla is pushing it as a privacy issue, in that using unencrypted DNS is where the privacy problem exists, and DoH is the solution. Today there are so few endpoints that support DoH that their only choice is to pick something, and go with it. Default settings matter, and in this case I think Cloudflare is probably a good default choice. At the moment “Cloudflare will never sell your data or use it to target ads. Period.” Assuming DoH becomes popular, then having the browser try the OS recommended name servers first, and a good UI to change the browser defined ones would be useful. At some point, it might even become possible to have the OS use DoH by default, and then all your apps, not just the browser, will be protected.

As said up thread, knowing the IP address is different than knowing the site. For example, my ISP knows I’m connected to 35.164.65.152, and they know that is ec2-35-164-65-152.us-west-2.compute.amazonaws.com, but which of AWS’ millions of customers am I connecting to? (Netflix.com in this case.)

It is easy to think of more nefarious examples than just advertising. Just as people running ad blocking host files or pi-hole can block ads, ISPs (particularly ones controlled by repressive governments) can use DNS blocking to limit access to undesirable sites. The UK is trying to use it to block porn, but other places use it to block access to news sites, messaging services, VPNs, and other stuff.

22

I don’t see DoH as an issue, but Mozilla/Cloudflare are also pushing an encrypted replacement for SNI (Server Name Indication), which is an issue for privacy.

Back when SSL was young, you could only map a single DNS name to an IP for SSL/TLS - the DNS name mapped to the IP that presented the matching SSL/TLS certificate. This was in contrast with HTTP, where virtual hosting allowed the web server to read the Host header in the HTTP request, and deliver the appropriate content. This allowed a single IP address to serve multiple websites.

The inability to do this in SSL/TLS was a major restriction, so an extension was added to the TLS specification - Server Name Indication. In the initial client connection request (the ClientHello), the client can specify the server that it is expecting to connect to. The HTTPS server can then present the correct certificate for the SSL/TLS negotiation and website content.

The problem is that SNI has to be presented before the server sends a certificate, and before the conversation is secured by encryption. In fact, the SNI name is sent as plain text, and can be sniffed out of the SSL/TLS conversation by ISPs, carriers, authorities and the like. Even for massively shared IP addresses (such as a Content Delivery Network like Akami or Cloudflare), the plaintext SNI inclusion allows identification of destination sites.

It’s also the case that the server certificate is delivered in plain text and can be sniffed. However, in the latest revision of TLS, (TLS1.3) the server certificate is returned after encryption is negotiated.

The Encrypted SNI (ESNI) proposal from Cloudflare and Mozilla does prevent this exposure, but does it by pushing this process to the CDN networks (notably, Cloudflare). A DNS/DoH lookup provides a IP address and includes a public key so that the SNI extension can be encrypted in the ClientHello. This is better, but the destination IP may still reveal the destination site. Here is where Cloudflare comes in - their CDN IP addresses host multiple HTTPS sites, so the destination address does not reveal anything significant. A further proposal extension allows the client to query the CDN IP address to get a list of supported SNI names.

The reason I don’t like this is that it forces companies that care about privacy for their customers into the hands of the CDN networks - they have to use a CDN network to prevent destination IP analysis, and they have to allow the CDN network supplying the terminating the IP address to be responsible for terminating SSL/TLS.

People are concerned about Google abusing DoH, but they ignore the play that Cloudflare is making here. If ESNI as envisioned by Cloudflare gets traction, then everyone hosting HTTPS gets driven into the hands of the Akamis and Cloudflares of this world. It would also seem likely that the big cloud providers (Azure/AWS/Google Cloud/Alibaba/etc) would get into the same space by providing the same sort of fronting services to aggregate IPs, delivering requests to cloud or remotely hosted sites via encrypted tunnels.