Slashdot Mirror
DNSSEC: Good Enough?
Phil Windley writes "DNS Security Extension, or DNSSEC, is a set of extensions to DNS, which provide end-to-end authenticity and integrity. Paul Mockapetris, the inventor of DNS believes DNSSEC is the answer to many of the identity problems on the Internet. He wants the IETF to get off the dime and approve the DNSSEC spec. A recent article in ZDNet TechUpdate interviews Mockapertis on DNSSEC (summary)."
D. J. Bernstein, the author of the supremely reliable and secure qmail mail server, wrote a proposal for a new Internet mail system a couple of years ago. It's called Internet Mail 2000. Check it out at:
...
http://cr.yp.to/im2000.html
The basic premise is this:
"IM2000 is a project to design a new Internet mail infrastructure around the following concept: Mail storage is the sender's responsibility."
It's an interesting concept and worth a read.
Unfortunately it doesn't look like it would do much to stop spamming, which is the major problem with the current internet mail infrastructure. For that, we need some way to make sending bulk email costly to spammers. Actually I'd say that this could be done already with current technologies, it's just that ISPs and large network providers are not being responsible in ensuring that the users of their networks pay the appropriate price for sending out SPAM.
Maybe ISP's should charge users for each outbound SMTP connection they make? I'd happily pay 10 cents per email I sent if it would reduce the amount of SPAM I received. It would only cost me a couple of bucks a month too at the rate that I send email
The summary: It's unfinished, the BIND company has poor implementations (like most everything else it implements), and won't provide a real increase in security. Interesting stuff.
It seems RIPE have a One Day Introduction Course for "DNSSEC and related tools, and the specific procedures set up by the RIPE NCC to secure the in-addr.arpa zone"
- Sig
Back when we didn't have DNS, pathalias was our dear friend. Gone, but not forgotten!
"To those who are overly cautious, everything is impossible. "
> Wouldn't working on a improved form of SMTP be a better project?
We covered that in a previous story and basically concluded that SMTP was too widely implemented (think embeded systems, etc) for a replacement to be viable within the near future.
The unofficial
Time for ICANN to be obsoleted by a nice DARPA funded project from MIT and Berkeley. The guys working on it are pretty bright, and DNS is what distributed hash tables are best for.
You can find it at IRIS
Certainly for dynamic DNS, you would want to know that the person redirecting "www.amazon.com" to a different IP address is really from Amazon, wouldn't you? Or do you not mind giving out your credit card number to random people?
"Freedom means freedom for everybody" -- Dick Cheney
DNSHijacker is one tool that facilitates DNS spoofing.
I don't understand the security issues here? I tried reading the FAQ but I'm a mumbling nincompoop. Can someone explain in a bit better detail about why we needsecurity for DNS? Is there any actual recorded instances of people breaking into the DNS database? Is this the website hacking I've heard about?
:'}
DNS is mostly a UDP-based protocol, and it's pretty easy to spoof. When you type "www.ibm.com" in your browser, a UDP packet goes from your computer to a caching name server at your ISP (I'm oversimplifying here, BTW, but if you aren't a DNS geek this is most likely exactly what happens). The resolving name server sends another UDP packet out to the root name server to find out who to ask about "ibm.com". Then the root name server says "go talk to ibmns1.ibm.com at 10.1.17.2". Then the caching name server talks to 10.1.17.2 and asks it to resolve "www.ibm.com". Then it sends a UDP packet back to your computer telling it the IP address for www.ibm.com.
Notice that all of these UDP packets went over the network in the clear, and you can see that there were quite a number of opportunities to spoof you. If I can do a root hack on the machine that's running your ISP's caching name server, for example, I can give you a bogus IP address for www.ibm.com, and then steal your credit card info when you try to buy something there. If I can watch your packets and respond faster than the caching name server does, I can also convince you to go to the wrong place. So it's not an insignificant vulnerability.
With HTTP, if you are smart, you check to make sure that your web browser is doing a secure transaction, but frankly, most people just ignore this issue, or don't even know what it means.
With DNSSEC, your resolver on your computer knows the public half of the root DNSSEC key. So it can verify the answer it gets, all the way from the top down to the bottom. If someone spoofs the response, the resolver ignores the spoofed packet, and you get the real one. If your ISP's caching name server is compromised, you can't look up www.ibm.com, and eventually you call your ISP and complain. They fix their nameserver, and you go back to your business, unspoofed.
As I said in a previous comment, DNSSEC is also a handy place to stash keys, precisely because you can validate them as I've described.
And, BTW, I glossed over a lot of details here. If you really want to know how this stuff works, you should probably read the RFCs...
There are certain aspects of DNSSEC that are infrequently discussed.
.com - I have heard that DNSSEC can make it take a very long time to come up after a change in zone contents. That's sort of having to wait for fsck to complete on a 500gigabyte disk every time you want to change a file in the filesystem.
First is that DNSSEC adds a degree of rigidity and inter-dependency to the net that makes it more brittle in the face of a natural or intentional disaster. When things have fallen apart, the time to recover is greatly increased if the rebuilders have to rebuild the security hierarchy before names can start resolving.
Another aspect is that DNSSEC tends to wire-in a single DNS root and wire-out competing roots.
Now, a lot of people think that competing roots are a horrible thing. And a lot of other people think they are a great thing. (I've been using competing roots for years with zero problems, so you can guess which camp I'm in.) And some communities (AOL) and countries, are not necessarily making noises that they really like the idea of one god-like root for DNS. (They want consistency, their concern is about there being a single authority.) Competing roots are also advocated as a way to escape captured regulatory bodies, such as ICANN.
For some of the big zones -
Paul Wouters from the FreeSWAN project spoke at DefCon 11 on DNSSEC... he has some materials online at: http://www.xtdnet.nl/paul/dnssec/
Nothing to see here; Move along.
Try again. IRIS hasn't proposed a thing that can solve DNS security issues. It might address decentralizing the mostly hierarchical lookup procedure (to address scalability for example), but this would in fact require something like DNSSEC so that DNS records could be verified as legitimate even when provided by untrusted/unauthoritative hosts in a DHT.
Your issue is easily handled by the bookmark file keywords provided by Mozilla Firebird. After you've bookmarked a page, you can return to it by typing in your personally chosen keyword.
It is interesting how this simple user interface feature provides a function you thought could only be provided by a central bureaucracy like the DNS. Hold off on the hyperbole a bit. There are some good solutions if you look.
I've worked through a lot of these issues with my YURL work.
The proposal for the secure nameserver is here: http://www.levien.com/fc.ps
And the draft thesis version is here: http://www.levien.com/thesis/compact.pdf
I originally started investigating trust metrics as a way to identify trustworthy, credible sources of name->key binding data. The trust metrics turned out to be interesting and useful on their own, and a lot easier to deploy successfully. I think there's a lot of important research still to be done on the problem, but I'm not especially hopeful that it'll get done any time soon. For one, if your goal is to avoid single points of vulnerability, you have to build the service as a peer-to-peer network, and we're still struggling with the best way to design those, even for relatively simple tasks such as media piracy^Wsharing, much less anything mission-critical.
I do hope that anyone seriously looking into the question of secure name services at least skims my thesis drafts. There are some good ideas in there, and I have a funny feeling that people will be remaking all the same mistakes I did.
LILO boot: linux init=/usr/bin/emacs
DNSSEC provides a secure key distribution mechanism. Right now, the only secure key distribution mechanism on the Internet is the SSL key mechanism, whereby a cartel of ~5 companies with keys that got into the original Netscape release essentially rule the roost, because Joe Average has no idea how to install a new root key in his browser. The cheapest key of this type will cost you ~$150 per year, and you can't use it to make more keys.
A browser key costs $250,000 per year, and $250,000 up front for audits etc., AFAIK.
If you think DNSSEC is vapourware, your information is outdated. As I presented in various talks this year at BlackHat, DefCon and CCC this year, DNSSEC is ready to be deployed, and IS deployed.
We are currently running over 150 domains in DNSSEC, using bind9 and some perl tools written by RIPE. We are using this to accomplish IPsec Opportunistic Encryption, which means massive deployment of IPsec tunnels by using secured DNS information for key material.
Please see:
DNSSEC is not vapourware. It will happen, and you want it to happen. Think about VOIP using the ENUM dnszone without DNSSEC. Do you WANT your phonecalls to be hijacked?
They have largely gotten over that shit. It is now permissable to export higher grade encrypton. The new NITS approved encryption, AES, will go up to 256-bit keys and is fine for export, they just want to see what you are exporting first.
h tm l
http://csrc.nist.gov/CryptoToolkit/aes/aesfact.
http://www.bxa.doc.gov/Encryption/
It's still not as simple as it should be (the government should mind their own bussiness) but it isn't illegal like it used to be.