You’ve of course heard by now that much of the Internet community thinks that SOPA and PIPA are bad, which is why on January 16, Wikipedia shut itself down, Google had a black bar over their logo, etc. This opinion is shared by much of the Internet technical community, and in particular much has been made of the argument made by Crocker et al. that DNSSEC and PIPA are incompatible. A number of the authors of the statement linked above are friends of mine, and I agree with much of what they write in it, but I don’t find this particular line of argument that convincing.
Background
As background, DNS has two kinds of resolvers:
- Authoritative resolvers which host the records for a given domain.
- Recursive resolvers which are used by end-users for name mapping. Typically they also serve as a cache.
A typical configuration is for end-user machines to use DHCP to get their network configuration data, including IP address and the DNS recursive resolvers to use. Whenever your machine joins a new network, it gets whatever resolver that network is configured for, which is frequently whatever resolver is provided by your ISP. One of the requirements of some iterations of PIPA and SOPA has been that recursive resolvers would have to block resolution of domains designated as bad. Here’s the relevant text from PIPA:
(i) IN GENERAL- An operator of a nonauthoritative domain name system server shall take the least burdensome technically feasible and reasonable measures designed to prevent the domain name described in the order from resolving to that domain name’s Internet protocol address, except that–
(I) such operator shall not be required–
(aa) other than as directed under this subparagraph, to modify its network, software, systems, or facilities;
(bb) to take any measures with respect to domain name lookups not performed by its own domain name server or domain name system servers located outside the United States; or
(cc) to continue to prevent access to a domain name to which access has been effectively disable by other means; and …
(ii) TEXT OF NOTICE.-The Attorney General shall prescribe the text of the notice displayed to users or customers of an operator taking an action pursuant to this subparagraph. Such text shall specify that the action is being taken pursuant to a court order obtained by the Attorney General.
This text has been widely interpreted as requiring operators of recursive resolvers to do one of two things:
- Simply cause the name resolution operation to fail.
- Redirect the name resolution to the notice specified in (ii).
The question then becomes how one might implement these.
Technical Implementation Mechanisms
Obviously if you can redirect the name, you can cause the resolution to fail by returning a bogus address, so let’s look at the redirection case first. Crocker et al. argue that DNSSEC is designed to secure DNS data end-to-end to the user’s computer. Thus, any element in the middle which modifies the DNS records to redirect traffic to a specific location will break the signature. Technically, this is absolutely correct. However, it is mitigated by two considerations.
First, the vast majority of client software doesn’t do DNSSEC resolution. Instead, if you’re resolving some DNSSEC-signed name and the signature is being validated at all it’s most likely being validated by some DNSSEC-aware recursive resolver, like the ones Comcast has recently deployed. Such a resolver can easily modify whatever results it is returning and that change will be undetectable to the vast majority of client software (i.e., to any non-DNSSEC software).1. So, at present, a rewriting requirement looks pretty plausible.
Crocker et al. would no doubt tell you that this is a transitional stage and that eventually we’ll have end-to-end DNSSEC, so it’s a mistake to legislate new requirements that are incompatible with that. If a lot of endpoints start doing DNSSEC validation, then ISPs can’t rewrite undetectably. They can still make names fail to resolve, though, via a variety of mechanisms. About this, Crocker et al. write:
Even DNS filtering that did not contemplate redirection would pose security challenges. The only possible DNSSEC-compliant response to a query for a domain that has been ordered to be filtered is for the lookup to fail. It cannot provide a false response pointing to another resource or indicate that the domain does not exist. From an operational standpoint, a resolution failure from a nameserver subject to a court order and from a hacked nameserver would be indistinguishable. Users running secure applications have a need to distinguish between policy-based failures and failures caused, for example, by the presence of an attack or a hostile network, or else downgrade attacks would likely be prolific.[12]
..
12. If two or more levels of security exist in a system, an attacker will have the ability to force a “downgrade” move from a more secure system function or capability to a less secure function by making it appear as though some party in the transaction doesn’t support the higher level of security. Forcing failure of DNSSEC requests is one way to effect this exploit, if the attacked system will then accept forged insecure DNS responses. To prevent downgrade attempts, systems must be able to distinguish between legitimate failure and malicious failure.
I sort of agree with the first part of this, but I don’t really agree with the footnote. Much of the problem is that it’s generally easy for network-based attackers to generate situations that simulate legitimate errors and/or misconfiguration. Cryptographic authentication actually makes this worse, since there are so many ways to screw up cryptographic protocols. Consider the case where the attacker overwrites the response with a random signature. Naturally the signature is unverifiable, in which case the resolver’s only response is to reject the records, as prescribed by the DNSSEC standards. At this point you have effectively blocked resolution of the name. It’s true that the resolver knows that something is wrong (though it can’t distinguish between attack and misconfiguration), but so what? DNSSEC isn’t designed to allow name resolution in the face of DoS attack by in-band active attackers. Recursive resolvers aren’t precisely in-band, of course, but the ISP as a whole is in-band, which is one reason people have talked about ISP-level DNS filtering for all traffic, not just filtering at recursive resolvers.
Note that I’m not trying to say here that I think that SOPA and PIPA are good ideas, or that there aren’t plenty of techniques for people to use to evade them. I just don’t think that it’s really the case that you can’t simultaneously have DNSSEC and network-based DNS filtering.
This post originally appeared on Educated Guesswork, Rescorla’s personal blog.
