EKR: January 2012 Archives

You have to have used git to really understand this one, but...

[16] git checkout f4a56
Note: checking out 'f4a56'.

You are in 'detached HEAD' state. You can look around, make experimental
changes and commit them, and you can discard any commits you make in this
state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may
do so (now or later) by using -b with the checkout command again. Example:

  git checkout -b new_branch_name

HEAD is now at f4a560b... Foo

As you may have gathered from this long warning, you most likely don't want to be in a detached head setting, you probably just meant to create a branch or wanted to rollback a commit but typed the wrong thing. Which is why there are lots of pages about what this means and how to get yourself out. My contribution to this literature can be found below the fold.

On my way to Red Rock today to do some work, I looked in my wallet to see if I had enough money to afford my hot chocolate (paying for a $3.50 drink with a credit card is a pretty lame move). Here's what I found:

After some sorting, it comes out as follows...

Currency	Count	Value (nominal)	Value (USD)
USD	3	3	3
CAD	7	100	98.55
CZK	2	2100	106.40
GBP	1	10	15.55
EUR	1	20	25.79
INR	1	100	1.99
RUB	9	1570	49.97
Total	24	-	301.25

In other words, out of 24 total pieces of paper valued at over $300, I had three spendable pieces of paper valued at $3. Oh, and a couple of United beverage vouchers which expire in 9 days. I ended up going to the ATM.

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

 

^1. Technical note: As I understand it, if you're a client resolver who wants to validate signatures itself needs to send the DO flag (to get the recursive resolver to return the DNSSEC records) and the CD flag (to suppress validation by the recursive resolver). This means that the recursive resolver can tell when its safe to rewrite the response without being detected. If DO isn't set, then the client won't be checking signatures. If CD isn't set, then the recursive resolver can claim that the name was unvalidatable and generate whatever error it would have generated in that case (Comcast's deployment seems to generate SERVFAIL for at least some types of misconfiguration.)

In Dahlia Lithwick's report on FCC v. Fox (about the FCC's TV indecency policy), she writes:

Justice Stephen Breyer raises a question about why the ABC ass case is being heard together with the fleeting-expletives case. Justice Ginsburg asks whether Hair could be broadcast on network television (Verrilli: "Serious questions") and then whether the opera Metropolis could be broadcast (Verrilli: "Context-based approach"). Then Justice Anthony Kennedy interrupts the parade of naked horrible to clarify: "What you're saying is that there is a public value in having a particular segment of the media with different standards than other segments." Verrilli replies that, yes, this is about preserving "a safe haven where if parents want to put their kids down in front of the television at 8:00 p.m. they're not going to have to worry about whether the kids are going to get bombarded with curse words or nudity."

Because if you want that, you can find it in the back seat of my car, at rush hour when we're late for Kung Fu. Just ask my children.

Kennedy replies that the V-chip is available and that "you ask your 15-year-old, or your 10-year-old, how to turn off the chip. They're the only ones that know how to do it."

I'm not saying this isn't true--though I rather suspect it's more likely that parents don't know how to turn on the V-chip [explanation here, in case you don't know] than that they don't know how to turn it off. However, I think discussion illustrates pretty clearly the confusion over the problem that people are trying to solve. (The terminology "threat model" as applied to children probably sounds funny to non-parents.) In any case, there are two different things one might be trying to accomplish with respect to potentially objectionable content:

• Prevent children from inadvertantly accessing objectionable content.
• Prevent children from intentionally accessing objectionable content.

If your objective is the former, then the V-chip works fine (except for the horrible UI); you just configure your device to suppress objectionable content. The sort of content-based regulation the FCC is engaging in works as well, assuming you don't let your kids watch TV except in the "safe" period, but it's a very inefficient mechanism compared to the V-chip, being both overbroad (affecting everyone, including people who don't have children) and not very effective, as it applies only to broadcast TV.

On the other hand, if your model is to prevent children from intentionally accessing objectionable content, and you further expect them to attempt to bypass content controls, then restrictions on broadcast TV don't do very much given that (a) if you have cable your kids can just tune to unrestricted channels and (b) large number of other sources of such content exist on the Internet. Blocking the tiny sliver of such content you still get through broadcast TV mostly looks silly and anachronistic. Though I guess it's less silly if you get hit with a huge fine for breaching the rather unclear rules.