SOPA-rope-a-dopa

Critics of the Stop Online Piracy Act (H.R. 3261) have had an impact.  A manager’s amendment has been offered by Lamar Smith, R-TX, the Judiciary Committee chairman.  I was critical of the first version.  Here’s my take on the new version.

This version contains several provisions aimed at the security concerns raised about the first version.  The new bill insists that it is imposing no technology mandate and that it should not be construed to impair the security of the domain name system or the network of an ISP that receives an order. And it whittles away at the original requirement that ISPs must “block and redirect” visitors to pirate sites. Now, the ISPs are only obliged to block those efforts, not to redirect the subscribers to an alternative site that warns against piracy. ISPs also get a safe harbor that allows them some assurance that they don’t have to redesign their networks to carry out the blocking.

Unfortunately, the new version would still do great damage to Internet security, mainly by putting obstacles in the way of DNSSEC, a protocol designed to limit certain kinds of Internet crime. Today, it’s not uncommon for crooks to take over Internet connections in hotels, coffee shops and airports -- and then to direct users to fake websites.  Users sent to a fake banking site are prompted to enter account and password data, which is used to loot the account. DNSSEC prevents such attacks by giving each website a signed credential that must be shown to the browser by the domain name system server before the connection can be completed.

That’s a great idea, but crooks will predictably try to override it.  Their best bet is to claim that the website doesn’t have a signed credential – a claim that will be plausible at least during the transition to DNSSEC.  What should a browser do if a website says it doesn’t have a signed credential yet?  The site might be telling the truth, or it might be a fake site backed by a DNS server that’s been tampered with.  To find out, the browser needs to ask a second DNS server, and if that server doesn’t give an answer, a third and a fourth server until it gets an answer. That’s the only way to keep criminals from blocking the real DNS credentials and offering their own.

Unfortunately, the things a browser does to bypass a criminal site will also defeat SOPA’s scheme for blocking pirate sites.  SOPA envisions the AG telling ISPs to block the address of www.piracy.com.  So the browsers get no information about www.piracy.com from the ISP’s DNS server. Faced with silence from that server, the browser will go into fraud-prevention mode, casting about to find another DNS server that can give it the address.  Eventually, it will find a server in, say, Canada.  Free from the Attorney' General’s jurisdiction, the server will provide a signed address for piracy.com, and the browser will take its user to the authenticated site.

That’s what the browser should do if it’s dealing with a hijacked DNS server.  But browser code can’t tell the Attorney General from a hijacker, so it will end up treating them both the same. And from the AG’s point of view, the browser’s efforts to find an authoritative DNS server will look like a deliberate effort to evade his blocking order.

The latest version of SOPA will feed that view.  It allows the AG to sue “any entity that knowingly and willfully provides …a product … designed by such entity or by another in concert with such entity for the circumvention or bypassing of” the AG’s blocking orders.

It’s hard to escape the conclusion that this provision is aimed squarely at the browser companies. Browsers implementing DNSSEC will have to circumvent and bypass criminal blocking, and in the process, they will also circumvent and bypass SOPA orders. The new bill allows the AG to sue the browsers if he decides he cares more about enforcing his blocking orders than about the security risks faced by Internet users. Indeed, the opaque language about “another in concert with such entity” makes perfect sense in the context of browser extensions.  It allows the AG to sue not just browsers but also add-ons with this feature.

OK, that’s the law.  Now imagine you are Microsoft, or Google, or Apple, or Mozilla.  The DNSSEC guys come to you and ask you to implement DNSSEC.  It won’t increase your revenue, they admit, but it will make the Internet much safer for your users.  You want to be a good internet citizen, so you think maybe you should devote some precious code-writing resources to the cause.  But first you ask your lawyers whether they foresee any problems. 

“Well, yes,” they’d have to say. “If you add code to the browser that implements DNSSEC, you’ll have to add code that circumvents criminal hijackings of the DNS system.  And that code can be declared illegal by the Attorney General pretty much whenever he likes.  You can litigate about it, of course, but if you lose, the AG can shut down all shipments of your browser until it’s been revised to the satisfaction of his staff and their advisers in Hollywood.”

Faced with that advice, would you implement DNSSEC?

Neither would I. 

In fact, I wouldn’t even allow the DNSSEC guys to write an extension that implemented their protocol. And so, by poising a sword of Damocles over the browser companies, SOPA will kill DNSSEC. 

Let’s hope that the opposition to SOPA hasn’t punched itself out against the first version of the bill, because this version is badly in need of a knockout punch.

Comments

[Daniel Castro]

You say "Faced with silence from that server, the browser will go into fraud-prevention mode, casting about to find another DNS server that can give it the address."

But, as you admit in this article, criminals are trying to trick users into going to their sites (either to install malware, steal money, or for identity theft). They are not trying to block users from accessing a site -- that doesn't pay the bills.

As you note, SOPA specifically says that redirection is not required. So why would users (or web browsers) think they are being attacked when they get a DNS timeout for visiting watchillegalmoviesforfree.tv? They are not being redirected anywhere.

Also, you say "Faced with silence from that server, the browser will go into fraud-prevention mode, casting about to find another DNS server that can give it the address. Eventually, it will find a server in, say, Canada."

Can you let me know what browser you are referring to that redirects U.S. users to a Canadian DNS server when it receives a DNS timeout error?

[Grumpybozo]

Daniel Castro asks:

"Can you let me know what browser you are referring to that redirects U.S. users to a Canadian DNS server when it receives a DNS timeout error?"

That sort of approach would not be implemented at the browser level. It is typically done in the DNS resolver, which in most modern OS's is a core system service. For existing Unix-like systems (Linux, Mac, FreeBSD, Solaris, etc.) making today's resolver implementations behave like that would be a trivial matter of configuration, e.g. reducing the timeout value and listing a diverse set of DNS servers in /etc/resolv.conf. A more robust but still relatively easy way to do it would be to run your own local caching resolver with query forwarding set up to ask name servers not subject to the decrees of your local tinpots.

People have been working to embed anti-authoritarian mechanisms into the technical standards of core Internet protocols and into their reference implementations for decades. The reasons for that are not political, but technical: to automate error recovery and make things work even when things they rely on are not entirely working. The canonical quip is: the Internet interprets censorship as failure and routes around it.

[Daniel Castro]

I agree with that assessment Grumpybozo. That means that Stewart Baker's comment that "It’s hard to escape the conclusion that this provision is aimed squarely at the browser companies. Browsers implementing DNSSEC will have to circumvent and bypass criminal blocking, and in the process, they will also circumvent and bypass SOPA orders." doesn't seem to hold up to much scrutiny.

[Dan Kaminsky]

Also, it's remarkably short sighted to cite present browser behavior when discussing impact against future browsers and specifications in agreement with well understood United States cybersecurity policy. Present browsers do not support DNSSEC well. That's not a problem to exacerbate, that's a problem to address.

[Dan Kaminsky]

Stewart's comments hold up to scrutiny just fine. In DNSSEC, signatures are *universal* -- all records, in all domains, are covered by one signature or another. Sometimes, they're signed in such a manner that the domain owner has a key to validate the existence or nonexistence of records. Other times, the domain isn't signed -- but its parent, generally the Top Level Domain, issues a signature *declaring* the lack of signatures for the domain.

When my code calls the secure resolution API, the lack of a signature on a domain that is declared to have signatures returns BOGUS. In other words, DNSSEC is an mechanism by which truth can be asserted, and here the API returns that a lie has been detected.

Now what? I have three options.

I can "fail closed" -- just give up. The problem is that there are a number of real world networks that are incompatible with traditional DNSSEC lookups. It's wild and wonky out there -- for example, the network I'm posting from at this very moment handles almost all of DNSSEC easily, except for a DNSSEC reply larger than 1500 bytes. Thus, it can't handle root key transfer. So, about 10-20% of the time, DNSSEC fails. This is insufficiently robust for widespread deployment.

I can also "fail open" -- try my best to get the secure records, but if I can't, oh well. I tried. This is a very robust solution. It is also utterly insecure. DNSSEC fails again.

What you end up having to do is implement a series of "fallbacks" in the case where the user is on a network that's not quite compatible with DNSSEC. These fallbacks include alternate servers, direct access to the DNS hierarchy, and various tunneling methods. This may seem strange, but it's why Skype is much more popular than your average SIP phone. We have to take extraordinary measures to maintain basic connectivity, so we can get to the 99.9%+ robustness that allows us to fail closed (and, of course, prevent a downgrade attack against the browser).

Oops, can't do that. May be robust, and may be secure, but it might actually not be legal. Do you think I can go to Mozilla, or the Chrome devs, and ask them to embed code that -- to maintain robustness under real world inclement conditions, interprets SOPA-driven blocks as the technical lie they are and bypasses them?

Here's the thing. At the moment they have to ask legal to join the product dev meeting, the meeting is already over. I've worked with *all* the browser manufacturers, and I've spent ten years working on the security problems of major software development firms. This isn't even a question.

So. Either DNSSEC code fails robustness, fails security, or fails legal. That computes to "fails to ship", and our best hope of addressing the onslaught of attacks vanishes.

Dan, there's a problem here, and you can't just "armchair IETF" your way into "DNSSEC has no problem with NULL responses". Your statement is false. Even if it wasn't false, your statement deserves time for a proper analysis, review, and test. Security fixes engineered on the scales of days are invariably disastrous. (Trust me, I've tried.)

[Daniel Castro]

Dan, you keep referring to "lies." SOPA does not require redirection. You know this. There is no "lie" if there is no response from a DNS server to a request to resolve the domain name of a known criminal website. You may disagree that a non-response is not a problem, but surely you can at least admit there is a difference between a redirection and a non-response.

[Dan Kaminsky]

Ah, my earlier reply got eaten. Lets retry this.

Dan, you're just not understanding. A lack of a response is still a lie. That's not a matter of opinion, that's what the API has to respond with. Nonexistence is asserted with signatures in DNSSEC. Here, look at this:

http://imgur.com/Kzs42

This is an NXDOMAIN response, with a pile of NSEC3 records (and their associated RRSIGs) accompanying it. In English, this is what a legitimate nonresponse in DNSSEC looks like -- an assertion there are no records at this domain name, along with records that declare the hash ranges within which there are no records (of which this is inside), along with signatures across that nonexistent declaration.

ISP's under the mandate of SOPA can't generate these signatures, because (by design) they lack the key material as assigned and delegated by the DNS hierarchy. So they have to choose, comply with the law or fulfill a moral imperative to protect their users. And it's the same with browser manufacturers, who aren't in the business of being hunted by AG's.

I think even you can concede, legal vs. moral, who wins.