Improving DNS Privacy with Oblivious DoH

The answer is - it depends.

If you own the device(s) (your internet connection, phone or a colo), and it is someone else's network - you want security.

If it's a device (smart tv, media player, iot) that you don't "own" on your network you want control.

In this case the client isn't sending traffic on port 53 at all — they already have the IP for the target server and so they just open a connection to it on port 443.

This is not hypothetical: it's how DoH works now but it's also how various things have worked for decades. Malware liked it for hiding command-and-control name queries from the few people who monitor DNS but it was also an option for anyone who had problems with buggy or malicious local DNS servers to add public resolvers like 8.8.8.8 or their own infrastructure into the search list so they didn't get support calls due to some ISP breaking their own DNS server.

The key part is remembering that this was always possible. DoH just meant that more people became aware of the gap they'd always had in their network management.

> DoH is highlighting the security nightmare that is AWS, GCP, Azure, Cloudflare etc with their reverse proxies and virtual hosts, making it impossible to safely restrict a network from communicating with only a specific cloud-hosted service.

This problem goes back a lot further than that — even prior to having CDNs in common usage you had plenty of different clients sharing IP space at hosting companies and the really malicious stuff just using compromised computers. It's also not fully covering the threat model here: for example, if you are concerned about privacy there are whole classes of device which you simply cannot allow because blocking one feature simply means that the vendor will run everything through the same endpoints required for the device to work.

> Also often perfect security isn’t required. Doors with locks are good, but useless if the burglar just breaks the full length glass window next to it. They still serve a purpose, but don’t need to be an absolute comprehensive solution.

Perfect is the enemy of the good but you have to also think about the asymmetry here. Trying to hijack DNS is only useful when you control the network but neither the client or server. Trying to stop malware by politely asking them to play nicely is a losing game and the IoT devices many people worry about have entire teams devoted to bypassing you as well (e.g. if any significant number of people tried to block a TV from reporting your viewing activity, the endgame is that viewing history and software updates would both go through samsung.com, not that they'll give up millions of dollars in revenue). That leaves you with cases where you do control the client and thus have less invasive alternatives such as installing an ad blocker or using a different browser.

DoH isn't blocking anything that any existing application can already bypass. It merely points out the fact that the rise in encryption makes it difficult for third parties to administer the software running your device.

DoH will not be extended to allow firewalls to decrypt it. The entire point of DoH is that firewalls cannot do that. It's not hard for an administrator to set up their own DoH server, though, so there is no need as long as that server can be configured at the network level. This is currently possible through group policies on Windows and most MDM applications on mobile devices.

The nice thing about encryption is that only the software and the server know what is being exchanged. The not-so-nice thing about encryption is that only the software and the server know what is being exchanged.

You already can't see the difference between your computer connecting to some S3 bucket to download a picture of a cat or malware connecting to a S3 bucket to get a list of IP addresses mapped to host names. It's possible to run fully-fledged VPNs that look exactly like normal HTTPS traffic on the network level. DoH changes nothing about that.

On enterprise networks, IT administrators can already put measures into place that prevent DoH on support applications and restrict HTTPS connections to trusted hosts (through SNI sniffing + validating the connection). The upcoming encrypted SNI will make this harder, but group policy will be able to disable eSNI on any trusted computers and browsers, leading only untrusted software to be unverifiable, which can then be reasonably classified as malicious.

If IT administrators cannot put measures on employees' devices then... well, they've already lost. Before DoH, they just didn't know that they'd lost yet.

Palo Alto currently blocks DoH by decrypting all TLS traffic (ranging from cookie recipes to naked pictures your phone is syncing to the cloud) with a man-in-the-middle attack which requires their certificate authority to be installed on your system. They filter out the DNS requests inside those TLS streams and apply some kind of rule to them. Right now, they can either block the requests or change the contents (as long as the website and/or client doesn't use DNSSEC).

With ODoH, changing the contents will no longer be practical, but blocking the connection will be. Together with decent group policy settings, networks with such a setup should be as safe as they were without ODoH.

On a side note: these types of middleboxes are often trying to be transparent and silently violate many standards, breaking stuff that works on every normal network. Stuff like these firewalls are the reason that TLS 1.3 is pretending to be a special type of TLS 1.2 every time it connects, because otherwise some big middlebox vendors' platforms freak out and kill the connection. I doubt the inevitable transition towards HTTP/3 or even HTTP/4 will do these boxes much good. I don't put a lot of faith in devices like this.

I have used CurveDNS forwarders at home as an experiment for many years now. I have never had any problems. I cannot see why authoritative DNS providers would resist offering DNSCurve as an option. It is relatively easy to set up and does not require replacing or modifying any DNS software.