A recent announcement from the US National Security Agency (NSA) regarding recommendations for the use of DNS over HTTPS (DoH) alongside the closure of the Mozilla Foundation call for input on the use of DoH in their Firefox browser has brought the DNS, regulations, and the role of the browser back into focus.
What’s at stake here, and what’s going on?
The three-legged-stool of the Internet
It’s often said, that the Internet is a three-legged stool of three distinct, but vital functions: take one away, and you lose stability.
- Distribution of unique addresses (the Regional Internet Registry (RIR) system).
- A mechanism to send things between them (Border Gateway Protocol (BGP)).
- A naming model to find the addresses for things (the Domain Name System (DNS)).
You can have a fine argument around a beer or meal about whether it’s really four, because you need a protocol to send things in, but that’s a conversation for another day. The key point here, is that we’re talking about the third leg of the stool: the naming model to find addresses for things. DoH is changing how we feel about that role, in this triumvirate. Therefore, it goes centrally to questions about the stability of the global Internet as we know it.
So what did the NSA actually say?
The NSA document basically says that DoH should be done with a DNS provider ‘inside’ your network boundary. Not that ‘DoH is bad’ but that ‘DoH makes some pretty big assumptions about who you send the DoH requests to’; that it’s better overall if you think about this, and use DoH as ‘channel security’ inside your local trust domain.
At one level, this isn’t entirely bad advice. There are significant risks to assuming your local network is ‘safe’ and being snooped on by bad actors ‘inside’ the defensive ring of your network is increasingly likely. The attack on the US Federal government systems in the supply chain pretty much created the situation that a Mac user might be walking into a federal agency network, plugging in, and having the Windows PC two desks down snooping on what they did on the LAN. So, a recommendation from the NSA regarding how to avoid ‘leaking’ your DNS query to people in the local net, is not actually bad advice.
The problem with the advice is twofold: firstly, there is a strong ‘shoot the messenger’ quality to the release of an NSA recommendation, leading to distrust in the advice. Secondly, it has consequences for some people who are seeking to use DoH to ‘leap over’ barriers to access a service inside their locally controlled network.
Should I trust the NSA?
The first problem relates to the reputational harm the NSA has done to itself in recent years by becoming embroiled in advice to the cryptographic community regarding the National Institute of Standards and Technologies (NIST) recommendations for cryptography. The NSA has a dual charter, one part of which is to secure US national interests, defensively, and examples of these cases, with merit, abound.
But another is to enable the US to do things at large, which non-US citizens and Internet users may have reason to question: the NSA is charged with looking at what everyone else does, as a risk to the US. By playing with the cryptographic standards process in NIST, the NSA devalued what NIST does in the space of standardization of cryptography, and thus, trust in the neutrality of agencies and their advice. Because of this, there is now increased concern that ‘if the NSA wants it, it must be bad’ for many people outside of the USA. European and Asian network operators are not looking at NSA recommendations as entirely neutral. So, in context, these network operators can’t help but ask:
“Does this NSA recommendation in DoH imply something that is potentially exploitable by them?”
I think this is a consequence of their actions in cryptography standards, but not actually applicable to this problem. The NSA recommendation here is to try and ensure agencies (and US networks in general) are protected against a class of risk that we know exists: the bad actor in your own network boundary. The reason they want you to do this, therefore, is partially for good in and of itself. The other half of the recommendation, is their stated concern that your trust in an outside DoH provider is possibly misplaced, and that it may not serve your interests to let that actor mediate DNS on your behalf. Well, that’s true, and has to be borne in mind. But, it also may suit me, in some circumstances.
And this brings the second reason to the fore.
Why do people want to use DoH? Sometimes, to skip over misapplied boundaries of control
DoH is a mechanism to tunnel your DNS over HTTPS, and bypass two things: blocks on specific name-to-address lookups (for example, a filtering DNS system implementing some kind of border control, local or national) and man-in-the-middle risks, where the address result isn’t actually the real provider and you are passed into an ‘intermediary’ who can see what you are doing. So, the prime desire for DoH could be that you want some basic privacy, but also it might be that you want to be able to use the network without an intermediary passing that data through a lens. This is slightly different to a simple concern over privacy.
Hotel networks are an example of a situation where the DNS is used to lock you into a relationship with the hotel, before they decide to let your packets pass. It is done to monetize the rental of time and bandwidth on the network. That’s their right, they own the hotel. But, alongside the filter that blocks you, is often a filter that directs you, to ‘trap’ all the DNS and make you walk through the hotel login and cash register. What DoH does, is ensure that after you’ve negotiated the hotel’s charges, you can do DNS without any concern. The hotel provider is still looking into your packets, monetizing what they see, and what they tell you.
Or, the ‘Great Firewall of China’, which typically uses the DNS to map things you aren’t ‘meant’ to be looking at inside China to 0.0.0.0 as an address, which then terminates inside China, so you cannot ‘get’ to, say, Google.
Ok, that’s all within their borders. The problem is that the ubiquity of services ‘hosted on Google’ but not ‘operated by Google’ in a narrow sense meant here, is now impeded. So, virtual domains in the cloud (for instance) can be adversely affected. Far more than just Google search is compromised when blocks on Google services occur in China.
DoH is well suited to this situation, because the DoH packets are not strongly amenable to the kind of interception being used here.
But what about ‘my network, my rules’?
Network owners may have their own ideas about how to run their networks. Let’s say they have young kids, and want to filter their access to objectionable content, or any content since they are loco parentis, and have rights and obligations. Bringing a device into the network, which bypasses their controls, ultimately denies them the right to be the parent and apply the rules. Isn’t there a valid case for having this control managed by the network owner? Sure! And, that goes to the side of the proposal the NSA have made: if you use DoH but limit its reach to the DoH provider your network host offers, you get assurance of carriage protection, and the network gets to manage things in line with their policy and legal expectations.
What about Mozilla?
The intersection into this NSA story, is that Mozilla is now capable of being the DoH intermediary, and has to make choices about how it exposes DoH (and similar technologies) to you, the user of their products and services. Mozilla owns the code behind Firefox and Thunderbird, and so directly implements its own network stack including the DNS, and now DoH functionality. What is Mozilla meant to do here? How does Mozilla expose control over the DoH settings to users? What defaults should it use and why?
These kinds of questions are what Mozilla was seeking to understand, mediating its role as an implementer of functionality. They’re good questions, respectful questions, which unfortunately intersect with the NSA recommendations, and desires of network operations people. Browsers are not answerable to these people, but cannot just ignore what they say, regarding what users want.
The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.