« More content than the Wall Street Journal -- and no paywall! | Main | Air France 447 and the Future of Socially Engineered Cyberwar »

Dec 14, 2011

Comments

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?

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.

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.

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.

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.)

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.

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.

The comments to this entry are closed.

My Photo
Bookmark and Share

Blog powered by Typepad