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
This sounds like a great idea. Let's present a new protocol. I suggest we name it Slashdot Mail Transfer Protocol. We could use the shortened form SMTP. hmmm well... on second thought maybe the name needs more work.
A lot of research and ideas and papers have been thrown around to replace SMTP with a better protocol but the costs involved are a major discouraging factor and people don't want to install a system when there is no guarantee that all the recipients have it too.
Maybe servers using a new mail protocol should be designed such that they first attempt to use the new protocol and if connect fails, try the good old SMTP
is it possible for the Slashdot collective to come up with another one?
Not a chance. The slashdot collective taken as a whole, is a very stupid group of people. Even the few intelligent people wouldn't be able to get anything useful done because they'd be shouted down by the teaming masses of idiots.
We hate Sony's recording arm, but we'll sell our souls to them for the next cool gadget. We hate MS, but 90% of us use windows on our main home machine. No to mention all the idiots who use words like boxen.
HELO imamailserver.com
250 Hello imamailserver.com [127.0.0.1] nice to meet you!
---
When I grow up, I want to be a kid again.
Do not send the message along with the envelope. Mail servers should only collect message envelopes, which contain information to obtain the real message. Then when someone reads their email their email program contacts the server to obtain the message. Thus you can't send email and vanish, since if you're not there when someone checks their email, they won't get your message.
Obviously ISPs will have to have the ability to store the messages of their users so they can deliver them while the user is offline, but that's no problem. If a user, or someone else, sends spam, once the ISP is notified, they can remove it from their servers, so that no further people who were sent the spam will actually recieve it upon reading their email.
Why I'm writing this I don't know. No one reads below score 3 anyway unless you're lucky and get one of the first 10 replies. Slashdot is useless. I'd shit myself if one person actually read this post. Hell, I can't even find posts after I make them, even after waiting several hours.
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's hard take a recommmendation from the inventor to seriously.
The Trust pyramid is the kicker, it seems these things fall into the hands of the untrustworthy. Almost analogous to the handling of domain names.
Whoever is at the top should be non-profit and transparent.
Nothing is ever good enough for /. readers, well except for Ogg Vorbis.
'Course it's good enough. Why, back in my day we didn't even have DNS; you had to send the domain to the next server via smoke signals, and that didn't always work so we often sent the packet data tied to the legs of birds. Of course, the going got real rough sometimes, usually around dove season...
Haven't we posted long enough about how none of us want anymore info on positively identifying ourselves online, and now this comes along? What is it we want, total invasion on knowledge of our whereabouts, or ability to be anonymous?
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
Protocol design and implementation are two very different things, as anyone who has ever configured and used BIND knows from personal experience filled with agony over buffer overflows from hell. I hope that DNSSEC code will be written at the level of quality of djdns.
Yes, Dan Bernstein is a very exasperating person and his code is hideously formatted, but it is effective, efficient and among the most secure code ever written. I still hate him though.
Of course, no discussion of DNSSEC would be complete without Bernstein's comments. And here are the slides from his talk in pdf.
Not being an expert on the topic, I find DNSSEC a little worrying, as it seems to be a consolidation of the centralized power of Verisign or whatever. Ideally we should be planning how to move away from traditional DNS altogether, as the single-rooted namespace has led to much political abuse. But that is a really hard problem to solve.
Quoth the article:
"The technology behind these confidence
checks uses digital signatures and
public key cryptography..."
First, find a way that I can get a "top level" CA to give me a certificate without charging me $US350 _per year_
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
I know RFC 1149 governs "packet data tied to the legs of birds", but I can't seem to find the relevant RFC governing IP over smoke signals, only a draft document. Was this protocol ever finalized? Can you provide a link? I'd hate to see people out there implementing non-RFC compliant IP over smoke signals -- that would cause massive interoperability problems!
"Freedom means freedom for everybody" -- Dick Cheney
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.
DNSSEC does require a top-level root key, but once you have registered your domain securely, you can generate keys whose public halves are *in the DNS* where anybody can get at them. That is, you can use your key to make more keys. Also, if you don't want to do business with one registrar, you can go to another, and as you are no doubt aware, the DNS registration market is quite competitive. So in fact DNSSEC is very democratic compared to its only current alternative.
Unfortunately, this is not a glitzy thing. This is nuts and bolts, wire dragged through conduits. DNSSEC is a really nice platform for building a more secure internet, but it doesn't solve the problem on its own - you have to build on it - e.g., using it to make SMTP more verifiable.
DJB says that BIND doesn't do DNSSEC very well. It's true that BIND 8 doesn't do as well as BIND 9. If you want to spend some money, my employer will sell you something even nicer. But the fact is that there are several free, working implementations of DNSSEC out there right now.
BTW, in the interests of full disclosure, I should say that I work for the same company as Paul Mockapetris (Nominum), and have in the past worked for the company that DJB styles "the BIND company," although I know much more about DHCP than about DNS.
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
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...
Let's say the Slashdot guys create a PGP key, publish the public key on the various keyservers, and start signing their web pages. Once I have a path from my key to theirs, I can be pretty sure that it's really them.
Even if I don't have a path, my future browser could record the key that's used when bookmarking a site. That way if I come back to it later and the key doesn't check out or another key has been used, then I know it's been compromised since then.
This could be used for other purposes. Let's say someone has a personal web page somewhere and is forced to move for some reason. You could be sure that it's the same person at the new URL because the same key would be used to sign the content. The best part is that whoever takes over the old URL can't spoof the old guy since they don't have his private key. All they can do is publish the exact data he already had out there.
Taken to an extreme, you could almost stop caring about URLs. You could look up someone by searching for their PGP key, and then work out from there. It wouldn't matter where they were actually hosted, since it is verifiably them. There would be no point in publishing phony information, since the key wouldn't check out.
DNS let us abstract away IP addresses to some degree. URLs can get us away from worrying about specific hostnames. Can this be the thing to abstract URLs away to some degree?
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 -
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
SMIME is a fine and lovely and centralizable way to do mail body encryption.
SMTP/TLS is a fine way to do transport encryption/authenication from one hop to another.
Lacking is a way - perhaps a signature header - for an MTA to "know" where a message is from. I'd love to be able to prioritize mail that's perhaps from "known good" domains. I believe IronPort is doing something proprietary along these lines.
Back to DNS:
DNSSEC tries to offer a way to ensure the content of a zone.
It's a good notion.
It's not been implemented well. I don't trust VeriSign, I certainly don't trust JoeBlow registrar. However, I'm willing to trust my domain and that's really what's needed when dealing with subdomains. And most of the meat of my DNS use is in the subdomains - every desktop, every server lives in a subdomain. www, ftp and MX records are in the top level - that's about it.
With BIND 9, I'm delighted that all my zones use notification and IXFR's (tranferring a 40,000 record zone over a DSL is not good without incremental zone transfers - esp in a DHCP heavy environment that can cause regular zone updates).
We can "extend" DNS with DNSSEC (or -alikes) because it's negotiable (like ESMTP is for SMTP). We cannot change how ALL DNS transfers and works by default without GREAT pain (we did that pain ONCE in 1980 going from NCP to TCP).
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.
It's unfortunate that the ICANN Gods want to require everybody in the world who sells domain names to get a True Name and Subpoena Address and ICBM address and Retina Print in Triplicate in return for letting you use the name, but you knew that when you got the name. And if you're using a subdomain Number-6.anonymous-cowards.com, and the people who run anonymous-cowards.com will let anybody get a subdomain name without providing all that personal data, you're still protected - you've got a cert that anybody who wants your IP address can use to verify that it's really yours and not some proxy server at fbi.gov.
Bill Stewart
New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
Maybe I'm missing something, but DNSSEC seems to go a bit overboard when trying to fix the major flaw in DNS today, the ability to falsify records.
Now, there are two ways to falsify records that I know of.
The first is a cross-zone caching issue where a DNS response contains records for a zone it doesn't control. This is a rather simple problem to fix and requires no changes to the protocol bitstream itself (though changes are required to how the protocol is handled). It basically involves applying a trust zone model and tossing some previously useful records.
The second is an ID prediction attack where a response to a DNS query is falsified by guessing the ID number of the query made by the DNS server. With a decent ID generator, this becomes difficult and you have to brute force the thing basically making it a one-in-a-billion chance. This is still too high, so modifications to the protocol bitstream are required to enhance the size of the ID field or add a secondary one. It is possible to hack in this with minimal compatibility problems, but it wouldn't be pretty. Alternatively having the DNS server simply query twice or use TCP would accomplish the same thing, though that slows things down a bit.
I fail to see how the leap to a full blown cryptographic PKI was made. Sure, technically it may be better, but it is also complex, intrusive and adds only slightly more security.
Personally, I'm happier with 99.999% security with minimal work vs. 99.99999% security with a complete overhaul of the system.
Maybe I'm missing something.
The world is neither black nor white nor good nor evil, only many shades of CowboyNeal.
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
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?