Feds Tighten DNS Security On .Gov 140
alphadogg writes "When you file your taxes online, you want to be sure that the Web site you visit — www.irs.gov — is operated by the Internal Revenue Service and not a scam artist. By the end of next year, you can be confident that every U.S. government Web page is being served up by the appropriate agency. That's because the feds have launched the largest-ever rollout of a new authentication mechanism for the Internet's DNS. All federal agencies are deploying DNS Security Extensions (DNSSEC) on the .gov top-level domain, and some expect that once that rollout is complete, banks and other businesses might be encouraged to follow suit for their sites. DNSSEC prevents hackers from hijacking Web traffic and redirecting it to bogus sites. The Internet standard prevents spoofing attacks by allowing Web sites to verify their domain names and corresponding IP addresses using digital signatures and public-key encryption."
How About They.. (Score:5, Informative)
They really need to crack down more on sites like this one: http://www.usagc.org/ [usagc.org] while they're at it.
WIN A FREE GREEN CARD! SIGN UP NOW FREE!*
* $100 entry fee.
Scam (Score:3, Informative)
www.irs.gov is operated by a scam artist
There, fix that for you.
Re:IRS vs. Scam Artists? (Score:3, Informative)
(you need to use HTML character entities: "comme ça". Slashdot only supports some—a fairly arbitrary subset—of these.)
Re:How useful is DNSSEC w/o top-level signed? (Score:5, Informative)
I've been told that DNSSEC is basically just a proof of concept when it's done on a single TLD, not providing much real security. [...] If so, then when your ISP queries one of the thirteen root servers for the .gov authority, the attacker could still return a fake response and set himself up as the DNS authority for .gov.
That would be my exact understanding as well.
The details are these: Every node in the DNS tree has a key pair. Everybody knows the public key of the root. Every response to a request contains an answer, and a signature on that answer. As an additional request, you can ask for public keys too.
So, here's the scenario for going to whitehouse.gov, assuming full deployment of DNSSEC:
This secures step 4. Step 2 is still not secured. Paul Vixie has given some good talks on DNSSEC and everything else that's wrong with the interwebs ;) See http://www.usenix.org/events/lisa05/tech/mp3/vixie.mp3 [usenix.org]. You may also like http://media.defcon.org/dc-13/audio/2005_Defcon_V7-Paul_Vixie-The_Internets_March_of_Folly.mp3 [defcon.org].
Re:How useful is DNSSEC w/o top-level signed? (Score:3, Informative)
This can deal with the Chicken-and-egg problem (Score:4, Informative)
This is a classic chicken-and-egg problem. The good news is that the U.S. government _CAN_ require that its OWN sites implement DNSSEC - and once that's done, people who deal with those sites (most U.S. citizens) will have a reason to install DNSSEC and the relevant
What will probably happen is that there will be a Firefox plug-in (if there isn't already) that supplies these keys, and slowly browsers will add support for all this. The result: Accessing these sites will become more secure, over time. Good thing.
Re:This can deal with the Chicken-and-egg problem (Score:3, Informative)
yes, there is one:
http://www.nlnetlabs.nl/dnssec/drill_extension.html [nlnetlabs.nl]
Why this is a bad example (Score:4, Informative)
Re:How useful is DNSSEC w/o top-level signed? (Score:5, Informative)
First, to answer your question regarding the plausibility: there are a few scenarios in which it is possible. The most likely scenario is that you're on the same local network as an attacker so that he/she can intercept your DNS traffic and forge replies. This might be the case when you're using the wireless provided at a coffee shop, for instance. There exist automated tools to make this simple, and I would consider this the biggest vector of attack. The only other case I can think of is that an attacker has control of a router between you and the root servers. While this is technically possible, I would personally regard it as fairly infeasible for the average attacker. If you're in $THIRD_WORLD_COUNTRY and the mob controls internet access, you might have something to worry about.
I'm involved with a project called SecSpider [ucla.edu] that monitors the deployment of DNSSEC. We use a distributed network of pollers around the world to collect RRsets from all known DNSSEC-enabled zones. One of the reasons we use pollers from different locations is to detect attacks such as either of the two listed above, more likely the latter. If any attack were to occur, we stand the best chance of detecting it. We have been monitoring since 2005 and have yet to see such an attack.
An additional benefit of collecting all these RRsets is that we have what we call a "world-wide perspective" on DNSKEYs. Whenever we collect a set of DNSKEY RRsets from a zone, if the set is consistent across pollers, we add it to our DLV repository. A DLV (DNSSEC lookaside validation) resource record is very similar to a DS (delegation signer) record. It contains a cryptographic hash of the DNSKEYs served by a zone so that the zone's integrity can be checked. However, instead of being served by the zone's parent, it can be served by anyone.
The typical way in which a resolver detects if a zone is secure is by tracing a secure delegation from the root. Instead of the typical manner of starting at the root and querying recursively for NS records, the resolver queries for both NS and DS records. Then when it queries one of the nameservers listed in the NS records, it asks for the DNSKEYs and verifies them using the DS record. In this way, it is possible to build a chain of trust that leads all the way back to the root nameservers.
Unfortunately, without the root being signed, this process will not work. One alternative is to configure your resolver to query for DLV records to bootstrap the process. When your resolver queries a zone for DNSKEY RRs, it will also query the DLV repository for a DLV recording matching that zone. It will then attempt to cryptographically verify the DNSKEYs using that record. If it verifies, you know that someone you trust thinks your DNSKEYs are right, side-stepping the typical chain of trust (thus the name: "lookaside"). If you were to configure your resolver to use our repository, you would be able to verify if the DNSKEYs you receive are the same as the DNSKEYs being seen by all of our pollers around the world. Not perfect security, but definitely an improvement on the current situation.
If you're interested in the details of our project, you can check out our web site or ask me for more details. We have information on how to use our repository in our FAQ [ucla.edu].
You mention the notion of real-world testing of DNSSEC. It's worth noting that there are actually several TLDs that are currently signed (mostly ccTLDs), as well as a large number of second-level domains. gov is hardly the first, but it should definitely be the highest-profile rollout to date. We're currently waiting with bated breath to see the outcome.
Re:This can deal with the Chicken-and-egg problem (Score:1, Informative)
Your "DRILL" .xpi addon only appears to be compatible w/ FF 1.5-2.x, NOT 3.x (the current series of FireFox)... see the bottom of that page, Lennie.