-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/756/a-case-against-dnssec-count-1-solves-a-non-problem/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
Does that mean I think it is perfect and secure? Of course not, but it does the job it should do. I'm not sympathetic to the view that DNS needs bloating, necessarily...
I will say I don't like the dismissal of DoS as an attack against DNSSEC. If attackers can just bring it down, all that other security seems pretty useless.
This is like, 90% of the motivation behind Bernstein's work on high-speed crypto and, in particular, high-speed signing schemes.
Having spent over 4 years at Arbor Networks, half of that in charge of their DoS product, which is deployed everywhere, I'm suspicious of any argument that says that DOS attacks are unimporant. The amount of effort people put into DOS is startling. And there's easy money in it: you just extort protection money out of casinos.
But just because they are important doesn't mean they need to be solved inside the protocol.
On the other hand, when a protocol's sole obvious benefit is being in a position to prevent DoS attacks, punting on DoS is a bit weird. That's a caricature of an argument though, presuming that you, like me, believe that all the rest of the "problems" DNSSEC "solves" are kind of silly.
Just to clarify, you're not arguing against the possible utility of unspoofable name lookups, right? Just that DNSSEC isn't it?
Or are you saying there's no point at all, and are concerned about the time wasted working on it?
Because I think I'd like to have the threat of name lookup spoofing removed to whatever degree possible, as an ideal.
Second, I'm trying to puzzle out whether you may be high, regarding more DNS servers in the world than SSH keys.
Things I can think of that are DNS Servers:
-Intentional, dedicated DNS servers
-Windows AD/DHCP/WINS boxen
-$40 linksys/dlink home routers?
-(Potentially) every *nix box and Windows Server box?
I'm reluctant to count much from the last bullet. While I'm sure most *nixes ship with DNS Server(s), I'm guessing they aren't on out of the box.
Other guesses are on the order of 9 million?
http://www.domaininformer.com/news/press/061009...
Now, SSH. I can't seem to find a simple OS market share link with just numbers instead of percentages, but I see a few that have "unix" looking in the neighborhood of 15-20% of the machines, and that's out of some few hundreds of millions of machines?
So, I dunno, 50 millions *nix boxes in the world?
I think a big chunk of those will be running SSH. I think most SSH Server installs will be generating the Server keys the first time you boot. Plus some possible multiples for user-side keys.
I believe some portion of those $40 routers also do SSH. While heisenburging, I'm perfectly willing to count the number of Windows boxes running SSH servers as zero.
So, back of my envelope says you're high.
http://blog.johnath.com/index.php/2007/03/21/re...
(And yes, of course neither of us invented the idea, nor am I implying we're particularly brilliant for invoking it, but nevertheless it sort of caught my eye.)
So, you look at the stencil for things that could apply to "security" and you get, uh, "key", "message", "deny sign", "alice and bob", "arrows", and "passport guy". I thought about using "ticket girl" for DNS but that seemed demeaning.
All joking and self-importance aside: the AIGA pictograms RULE, and they're open-source (really, Alan!). You can get 100x better diagrams tomorrow by:
1. Using black and white and one or two accent colors.
2. Never using single-pixel strokes for borders.
3. Drawing a guide box to represent a plane for all your little icons to live on.
4. Using the AIGA symbols instead of trying to draw your own stick figures.
5. Picking one typeface and sticking with it.
You too can be a bad, wannabe graphic artist!
Somebody devil's advocate!
I think you overlook one potential use of a secure DNS. You say -
"Securing the DNS protects DNS lookups. But Alice and Bob still need another layer of security."
You mention that web-of-trust (PGP), CAs (PKI), or key continuity (SSH) all can bootstrap this other layer of security.
But so could a secure DNS! Consider the potential for putting, say, key fingerprints in DNS to authenticate MTAs and webservers. Or policy information indicating "all emails from this domain are signed".
I think your argument against this would be that key-management external to DNS is superior due to the end-to-end argument - it's better to have specialized third parties "whose only job is to protect cryptographic secrets" than to burden DNS with this.
However, when you really look at it, whether the function of providing authenticated (domain-name, public-key) mappings is best provided in DNS or by external 3rd parties is not immediately clear.
For example, how are these third-parties going to check that someone really is the correct owner of "example.com" before issuing them a certificate? By checking with the domain name infrastructure? In that case, the domain name infrastructure already is the authoritative source for this information, and already has the capability of delivering it efficiently to requestors. So introducing 3rd-party CAs is introducing an additional point of control, security risk, and protocol complexity, and it's not clear that the gains of, say, more centralized private-key security, compensate for that.
Anyways, certainly CAs can be useful in certifying attributes besides domain-name - e.g., "the holder of this key is a trusted financial institution" or somesuch. And it may be that these other bindings are more important than (domain-name, public-key) bindings.
However, if authenticated (domain-name, public-key) bindings do have value (and I think they do), then it would seem to me that a secure DNS is a fairly elegant way of providing this. (though I'm not familiar with DNSSEC enough to know whether it's the best way to provide this).
My 2c, anyways... Cheers.
I really would like to see secure name resolution, I don't see any good reason for that problem to not be solved eventually.
I know basically nothing about DNSSEC, so I'm happy to take your word for it that it's a mess. I don't know much about IPSEC either, but it didn't take me long as a VPN administrator to not like it.
I also have little faith that a big standards committee is going to come up with the "right" solution. So, I can't lobby that the IETF whatever needs to try again. It's like thinking there should be a law, and not trusting the lawmakers to get it right. That's why a lot of people are afraid of Net Neutrality.
And finally, I'd have to agree in many ways that this isn't the highest priority in the security world. I didn't know there was a limit to the number of efforts, I thought they kind of went in parallel. But yes, there's a limit on our ability to consume new standards.
So I don't have any good basis for arguing with you. Sorry.
Next time, though.
Also, the DNS MitM protection assumes that people are somewhere on the Internet, and can subvert DNS, but cannot subvert sshd or the server OS, in which case they can steal the unencrypted hostkeys and impersonate all they want, or simply eavesdrop without affecting the client-server communicatons at all.
Trevor is totally, 100% correct.
I simply propose then that we evaluate the -SEC seperately from the DNS-: create a totally seperate hierarchy, run the protocol on different ports, get it the hell out of BIND, and use it solely as a building block. But leave the DNS hostname resolution system alone, because it works well enough now.
Trevor, I have 3 more detailed posts coming on this, and I'd love to see if the rest of my arguments influence you. =)
We're pretty paranoid about this, so maybe we're not representative.
Of course, in the current state of the art, key verification finds its asymptote at browser cert verification, which end-users completely ignore. The same security problem you point out for SSH ALSO occurs if you click through the browser warning. When you discuss getting any better than browser cert verification, you are talking about making SSL/TLS more attractive, and thus (by my reasoning) making DNSSEC LESS attractive.
(Yeah, right. But Dave is going to make me put a dollar in a jar every time I say it!)
Yes, SSH warns you when keys change out from under you, but there are 3 major categories of threat here, and this protects you from the uncommon one.
1) If I subvert DNS and interpose my machine running sshd for yours, hostkeys will warn you. But I've never seen that happen (not that it doesn't, that it's uncommon).
2) If I break SSH (which used to happen all the time, but has definitely tapered off), I 0wn sshd, and grab its keys. You can't tell you're now talking to a compromised sshd.
3) If I break into the host OS any other way and get root, I can "upgrade" to my own compromised sshd binary and keep the old keys. We upgrade sshd all the time, retaining keys. No help from hostkeys here.
3a) If I'm really sneaky, I could grab the hostkeys, and tap port 22. If I have the hostkey, I should be able to eavesdrop on all communications either way by "following along at home" and replicating the host's crypto calculations with its key.
I think you finally hit the nail on the head. Protocols are generally not the answer because technology cant fix social problems on a large scale. This has been under my fingernails for a while now but I dont think the idea will be generally popular with anyone. The Internet isnt broken and cant be fixed. People are broken. The "fix" tends to come from social structures and laws (and law enforcement).
In any case its not SSL/TLS or the Verisign protection racket goons which secure your purchases from Amazon or your ebanking; its consumer protection laws which limit your liability for misuse of your credit card or protect you from bank fraud (in the US anyways, the rest of the world is different).
SSL/TLS/PGP/SSH are due dilligance practices. DNSSEC may or may not be in the future.
But seriously. All hyperbole aside, I see your points but for reasons of practicality, I dont entirely agree with your assertion that authentication should be solved at a higher layer.
And, as I hope my next 2 posts make an adequate case for, I mean "bad" in your first sense. "Really" bad.
I agree with everything you wrote here. BTW, I love the illustrations too.
Regards
For the paranoid among us I found this interesting:
http://www.theregister.co.uk/2007/04/03/dns_mas...
I wonder how much truth there is to in and if this is in anyway going to cause the US Gov to try and push DNSSEC forward.
.~.
3a) If I’m really sneaky, I could grab the hostkeys, and tap port 22. If I have the hostkey, I should be able to eavesdrop on all communications either way by “following along at home” and replicating the host’s crypto calculations with its key.
I don't think so - can you also follow the Diffie-Hellman calc?
The last point about BIND having many security flaws related to DNSSEC is an interesting one. I use tinydns myself, and was actually looking into DNSSEC after reading about irs.gov implementing it (Slashdot). Apparently tinydns does not support DNSSEC, nor is the author interested in it for a lot of the flaws in the system you pointed out.
"I'm not going to bother implementing DNSSEC until I see (1) a stable, sensible DNSSEC protocol and (2) a detailed, concrete, credible plan for central DNSSEC deployment. " - http://cr.yp.to/djbdns/forgery.html
A chicken and egg problem I guess! Anyways, kudos on the informative post.