Kaminsky On DNS Bugs a Year Later and DNSSEC 127
Posted
by
CmdrTaco
from the i-feel-safer-already dept.
from the i-feel-safer-already dept.
L3sPau1 writes "Network security researcher Dan Kaminsky has had a year to reflect on the impact of the cache poisoning vulnerability he discovered in the Domain Name System. In the time since, Kaminsky has become an advocate for improving security in DNS, and ultimately, trust on the Internet. One way to do this is with the widespread use of DNSSEC (DNS Security Extensions), which essentially brings PKI to website requests. In this interview, Kaminsky talks about how the implementation of DNSSEC would enable greater security and trust on the Net and provide a platform for the development of new security products and services."
Re:Optimistic guy (Score:3, Interesting)
Re:You obviously have no idea what your talking ab (Score:0, Interesting)
http://it.slashdot.org/comments.pl?sid=1134339&cid=26924561
So, did Kamisky find a flaw in dns, or just bind? He's a blowhard.
(I'm not #1311235)
Need DNSSEC tools (Score:3, Interesting)
1) implement BIND and do the key management and rotation from the command line
2) spend $10,000 or so for an appliance from secure64 or nixu
3) spend $1k/month for a hosted DNS provider like neustar or verisign
4) install Win2008R2 RC and use it in producition
I work in a windows shop, so I'll probably go with option 4, but I'm surprised there aren't more set-it-and-forget-it tools out there for DNSSEC deployment. I'm open to recommendations.
Re:You obviously have no idea what your talking ab (Score:0, Interesting)
Re:Optimistic guy (Score:3, Interesting)
Questions from a DNS implementor (Score:5, Interesting)
OK, since Mr. Kaminsky is following this thread, I figured this would be a good place to open up some questions and a discussion between a DNS implementor and Mr. Kaminsky.
Let me introduce myself: My name is Sam Trenholme and I am the implementor of MaraDNS [maradns.org], a recursive and caching DNS server. Right now, I am in the slow process of re-writing the recursive DNS resolver [blogspot.com]. While MaraDNS has always been as secure as non-DNSSEC can be against Mr. Kaminsky's bug [blogspot.com] (DJB knew about the problem back in 1999 and I implemented his solution to randomize both the query ID and the source port back in 2001), I am wondering:
How hard is it to implement DNSSEC in my recursive cache? How many RFCs am I going to have to toil over to understand DNSSEC well enough to implement it? About how long will it take me to code MaraDNS to have full DNSSEC support?
I have a bad feeling that DNSSEC is a monster to implement and that we will not see many independent implementations of it; right now BIND and Unbound appear to be the only DNS servers to support it. DjbDNS doesn't support it, of course, and probably never will. My own MaraDNS and PowerDNS also don't support.
What are your thoughts? Has a reasonable effort been made to make DNSSEC easy to implement?
Re:Optimistic guy (Score:4, Interesting)
(This is Dan)
Sure, DNS is a single point of failure with security implications. What else is new? Half my talk last year showed what sort of damage you could do if you could corrupt any DNS name. The root can, today.
It also scales really, amazingly, wonderfully well. See, DNS actually delegates, unlike X.509. That means the root doesn't interact with most people, just a few countries and gTLDs.
So, how many people do you have in your GPG keyring? Few dozen? Few hundred? I spent six months interacting with people over email securely. It added an average of 72 hours of time before work could be done, and often it didn't work. C'mon, this ain't scaling.
Re:Optimistic guy (Score:3, Interesting)
(This is Dan)
That's interesting if you're just trying to secure DNS. We have much bigger fish to fry -- fish that require us not trusting the NS at Starbucks.
Question for Dan: signing the root (Score:1, Interesting)
Hi Dan,
Stupid question: can whoever holds the root key forge requests from all domains?
e.g. if I am the US government, can I spoof an .ir domain?
Thanks.
Will DNSSEC my ISP's dns hijacking? (Score:1, Interesting)
I've got verizon and when I look up non-existent TLDs I get back a records of 8.15.7.117, 63.251.179.13, and 67.63.55.15.
Now, maybe that would be cool if I were using their DNS servers but I'm using dnscache running on localhost, so they're hijacking requests to root servers.
So, WTF, and will DNSSEC make any difference in this?
Re:Questions from a DNS implementor (Score:3, Interesting)
(This is Dan)
Heh Sam,
It's a bit tricky, but we can work with you on the trickiness. DNSSEC is *much* easier to implement if you drop the somewhat unnecessary requirement for offline key signing, which is why BIND is so messy. Libunbound/ldns is flexible enough so you can integrate it, otherwise we can help you with the various wonkiness. Email me offline, dan@doxpara.com ?
Re:new security products and services? great. (Score:0, Interesting)
I don't care if you really did invent the Internet.. This does not make DNSSEC any less of a retarded idea.
The Internet can not be free and trustworthy at the same time. Keeping the network dumb and the edges smart where trust is best positioned to be established is the only design decision not rooted in nonsense.
The problem with IETF standards process is that the realistic concept of "more is less" or "good enough" is constantly drowned out by the voices foolishly seeking to write the perfect protocol even if the result is unreasonable in practice or adds significant complexity and overhead without providing any tangable benefit in return.
The Internets DNS does *NOT* need to be secure -- It mearly needs to protect against everything short of an active MITM which requires less than an ounce of cryptography to implement effectivly.
Making the trust anchor so large that it encompasses the entire planet for a given tld is the very definition of futility. Some hacker or government somewhere will eventually get a root key and sign whatever domain they damn well please regardless of how careful and dilligent all of the players involed are.
Now for corporate/intranet environments DNSSEC has a great deal of value.
Re:I don't wanna put a subject. (Score:3, Interesting)
There already is a standard: SSL. It includes encryption (to secure the content going across the channel against eavesdropping) along with bidirectional authentication (server certificates to verify that you're talking to the server you think you're talking to, as well as the less-commonly-used client certificates to authenticate to the server that you're who you claim to be).
If I were setting up a secure site, it'd be SSL-only. As part of the account-setup process, you'd be asked to generate a client certificate and upload the public certificate (over an SSL connection) to the server to be attached to your account. From that point on, when you attempted to log on using your username the server would only accept the request if it came over a connection presenting the client certificate attached to that username. And I've long suggested that, for user security, browsers have a feature where the user can associate server certificates with identities and then, by selecting an identity to communicate with, limit the browser to accepting only servers presenting one of the certificates associated with that identity. Have a way for the user to download the server certificate as part of the account setup process and you pretty much eliminate the need for PKI to support the whole thing, self-signed certificates will work since they were gotten directly from the source. You still need verification of both ends, but it's limited to just during the account setup process and isn't an ongoing thing.
Re:Optimistic guy (Score:1, Interesting)
How much network traffic will DNSSEC add to the network?
Re:You obviously have no idea what your talking ab (Score:1, Interesting)
DNSSEC must be the most wildly overrated technology to ever come out of the internet.
Seriously, it's just terrible from a system administrator's perspective.
It's been a year since I listened to a speech about DNSSEC (from an official ISC representative) at a Linux User Group meeting, so I don't have every last detail on the tip of my brain. However, it provides a little more security in some ways, while making other things worse.
Among the highlights:
- You need to sign your DNS zones every thirty days or so, because the crypto in DNSSEC isn't really that good for speed optimization reasons
- If the signatures on your DNS zones expire, any validating DNSSEC resolver will pretend like your zone doesn't exist (since it was too late to use anything other than NXDOMAIN to indicate signing problems to keep backwards compatibility)
- You therefore need to set up a cron job on a second server to make sure that the DNS zones were signed properly. At the time this bug was published, there weren't any tools to do this in a sane manner, so you'd have to write your own scripts
- If you are an ISP, running a validating DNSSEC compatible resolver will likely end in more customer complaints, since it treats signed-but-expired DNS zones as NXDOMAIN, whereas a standard DNS setup would continue to work. Paul Vixie himself ran into this problem with one of his domains, forgetting to sign the zone in time and having it fall off the internet for anyone using a DNSSEC enabled resolver.
- As one of the new requirements of DNSSEC, it is now impossible to not publish a list of every single subdomain on your DNS zone. This is because every record in the zone has a pointer to the next record, kind of like a circular linked list. ISC maintains that this is no big deal, but there are plenty of people (myself included) that feel otherwise.
- The root and second level DNS providers are probably not going to support DNSSEC, or at least that was the feeling a year ago. As a result, ISC came up with something called DLV, or Domain Lookaside Validation (RFC 5074). This essentially sets up ISC as the official arbiter of which second level DNS zones (like google.com, microsoft.com, etc) are official and can sign their own zones.
ISC may not be selling anything, but they stand to gain significantly if they become the de facto authority on which internet domains are valid, and the presentation was more full of FUD than anything I had ever heard come out of Microsoft. Seriously.
I got the strong feeling that DNSSEC in general really feels half baked and rushed out, rather than something simple and well thought out. I would advise everyone to avoid it like the plague, and hold out for a better solution.
Re:Questions from a DNS implementor (Score:3, Interesting)
Re:new security products and services? great. (Score:4, Interesting)
(This is Dan)
I actually completely agree with your desire to see trust in the edges. That's what's so interesting about DNSSEC -- DNS, by its very design, is all about getting the core the hell out of the way and delegating, delegating, and delegating some more until the organization that manages the namespace can directly control it.
Indeed, in the ultimate vision of DNSSEC, we have full on validating resolvers in clients. The endpoints themselves can finally - finally! - recognize their peers directly, without having to trust anyone or depend on the admitted messiness of the existing SSL CA infrastructure.
The reality about Active MITM is that it's out there. See the BGP work that came out in tune with my talk -- note that all that still works, today, even with my big fix. Active MITM isn't some theoretical attack, and the reality is that everything is vulnerable to it. An ounce of cryptography is worthless without a metric asston of key management. DNSSEC is just the best way I can see to do it.
Regarding the trust anchor size, the reality is that we have 25 years of it not being a problem. That's the simple truth. Everything I did last year could have been done by a malicious root. It wasn't.
Your corporate/intranet myth is funny, because it strikes at the heart of the problem. You think there's just one corporate/intranet to authenticate. It's literally like you're suggesting, email to other companies is complicated, so lets just do email to our own company. Nice, but not good enough. We need cross organizational trust. We need something to bootstrap it. DNSSEC should be that.
Re:You obviously have no idea what your talking ab (Score:4, Interesting)
(This is Dan)
There's lots of shysters in every field. Doesn't change the fact that there are problems out there that need fixing. Security is in fact a problem.
In concrete terms, just for my vuln, about 1% of one of Brazil's largest bank's customers had their info taken by my bug. That wasn't fun. And China Netcom got hit pretty hard too, go Google that. Of course, there's a lot of data we're missing, because nobody needs to report. But anecdotally, this was a problem, but not the end of the world. Good! I didn't exactly set out to end the world :)
In terms of what I see fixing, I see a lot of technologies repeatedly sold as "and then you get certificates", and nobody does, because it's just such a cross organizational nightmare to manage. Certs aren't working, and it's holding back auth technology after auth technology. Verizon Business' data says that 60% of vulns aren't implementation flaws -- they're authentication flaws, with passwords at the heart of them.
Why so many passwords? Because they work. Well, DNS works too. Maybe we can use it to make all the better things scale across organizational boundaries.
Re:Optimistic guy (Score:3, Interesting)
I don't mind SSH, with its key caching, but what about initial trust? What about the fact that, in the real world, keys change (just like IPs change) and when they do, something needs to say the new content is OK? It'd be nice to have a system that existed independent of any given server, which could (through a *delegated chain that didn't require cross-organizational begging*) assert the validity of new content.
The root servers were there 15 years ago. They'll be there 15 years from now. That's a fantastic foundation to build just what we need.
It's because the PGP keyservers get stale data, and the entire revocation system doesn't work. I have multiple keys in there I can't get rid of, because I don't have a business relationship that lets me identify myself and I don't have the key material to eliminate the key. Go look through the data, it's a mess.
In the end, the keyservers work better than web of trust, but not much better.
Re:Optimistic guy (Score:3, Interesting)
(This is Dan)
Hehe. OK, I like you foom. Lets talk.
So the deal is, DNSSEC lets the server at Starbucks cache DNSSEC records for you. So even if it's not doing the validation, it can at least remember the crypto such that each backend host that is doing validation can enjoy the cached records on the shared NS.
You can't do that with DNScurve, since the crypto is link based.
I've been playing with the Curve25519 code lately. It's cool, I have use for it (understatement), and it's a joy to work with. But DNScurve has a design limit, and we need a little more than it can accomplish.