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."
Kaminsky is incredibly enthusiastic about DNSSEC.... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.
Security is a tricky thing. You say security people sell you things "you don't need". But if you wait until you NEED security, it is already too late because you have a breach.
Security is not an ER visit, it is a regular preventative exam with your physician. It is something you have to take a pro-active approach with. Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.
There are numerous issues with implementing DNSSEC. The idea has been around for like 14 years now. Also, there are alternatives like DNSCurve which provide more security with considerable ease of deployment.
DNSCurve can't achieve end-to-end security while still caching. Without the former, you're trusting the name server at Starbucks not to be malicious. Without the latter, there's a 10x (minimum) increase in DNS traffic and the internet collapses.
There's some really interesting math going on, but operationally DNScurve isn't a good path.
That being said, there are some really interesting things from DNScurve we can integrate into DNSsec without any code mods. Key rollover is a mess in DNSSEC, and it's somewhat unnecessary.
I'm just going to repost my last comment on this subject. I don't think things have changed since then, but if they have I'd certainly be interested to know.:)
You might be interested in this thread: https://lists.dns-oarc.net/pipermail/dns-operations/2008-May/002736.html [dns-oarc.net]
where Paul Vixie recommends that nobody should ever deploy a stub resolver that supports DNSSEC, but instead use TSIG to talk to the recursive resolver. Which really makes DNSSEC's security characteristics look very much like DNSCurve. Th
DNSSec doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because you can't do DNSSec from a stub resolver and have to use TSIG (which protects the client->server data transfer, not the zone data).
DNSCurve doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because DNSCurve protects the client->server data transfer (of each step of the process) not the zone data.
You're screwed either way.
Or, you can decide to either use a different resolver somewhere on the interne
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 DNS
The one difference is that in most cases the recursive resolver will be under the control of either the user themselves or the owner of the network. Eg., home computers implement stub resolvers talking to the nameserver included in the home router, which does the DNSSEC. You have to trust the server the stub resolvers are talking to, but that server's the little box sitting on the shelf above your computer instead of some random nameserver several hops out under the control of someone you don't know. Or you
Well, I was one of the guys who was wrong (about DNSSEC, anyway) so it doesn't completely match up.
Look, simple question: Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't. All I see are crappy passwords everywhere, being left as default, getting leaked, being brute forced, etc. Most security technology isn't working.
DNS works well. Seems to me more things should work like it.
I find the (Slashdot) story title and summary to be a bit misleading, though I doubt that was intentional. As a result, I think most of the replies to you fail to appreciate that you are not really talking about fixing a flaw in DNS; you are talking about using DNS as an infrastructure to make many more things start depending on it. From TFA:
DNSSEC is interesting not because it fixes DNS. DNSSEC is interesting because it allows us to start addressing core problems we have on the Internet in a systematic a
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.
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.
I guess what I am asking is this: such a failure that results in corrupting a DNS name is already bad enough. Would it not be worse if many other security mechanisms also depended on it?
What makes DNSSEC better than using protocols (such as SSH) which can independently verify the identity of a host by
What makes DNSSEC better than using protocols (such as SSH) which can independently verify the identity of a host by means of cryptographic signatures? This to me also seems consistent with the idea that good security is done in layers, not by single ultimate solutions.
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 sys
> Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't.
I don't, IMO they are just a way for Verisign and Friends to collect toll.
But I don't see how DNSSEC fixes that at all, it just makes it easy for Verisign et all to collect yet more toll.
If people were really interested in security they would have the https cert stuff behave a bit more like ssh does, e.g. if the browser notices the cert for myfavbank.com has changed, and now signed by
Have a look at the Firefox Perspectives add-on, it's meant for telling you when a self-signed cert changes, but can also be configured for use with normal certs.
You can get wildcard certs. for HTTP as well. They cost lots and lots of $$$
You wonder how much getting a domain signed is going to cost... thing Verisign is going to turn down a cash cow that big? I'd be surprised if they charge less than $1000 per domain.
Ultimately, as Verisign signs the root, all paths (and all money) leads to them - and that's why they're pushing DNSSEC so much.
Personally, when i type google.com into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.
See, it's boring people like you who take the fun out of web surfing. Down with DNSSEC!
I haven't deployed DNSSEC yet on my external domains because of cost/complexity. When I looked into it, my options for DNSSEC were:
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.
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.
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?
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 ?
I'll post a summary of the discussion to my blog [blogspot.com]. I welcome open discussion, but I feel more comfortable posting to a place where I can filter out the trolls.
36 RFCs [dnssec.net] over the course of 12 years for a not-even-deployed-yet standard really is quite excessive. I don't blame him for thinking it's going to be a monster...
Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)". Oh, the DNS part wasn't:) Yeah, I know its a very common acronym.
I was actually thinking about this the other day.
Http has absolutely no security at all built into the protocol. It is all hacked together with cookies and the server remembering sessions etc.
The protocol itself is dumb. Make a request... get a response, thats it. Any security is on top of that.
If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.
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 certi
That isn't what the original poster meant by security. Encryption only secures the transport, that does not mean SSL and TLS secures HTTPS from any exploits.
Well, SSL/TLS can, with the proper use of certificates, secure the endpoints against impersonation attacks. If, for instance, the browser has the server's certificate directly in it and won't accept any others, then it doesn't matter if the attacker can redirect the traffic to their server and forge DNS perfectly, the browser will still reject the server because it doesn't have the certificate the browser expects. Ditto the other way using client certificates. An attacker would have to compromise the endpoi
The Kaminisky bug is real, and its being used out in the wild. This is not a hypothetical academic exercise. DNS needs to be secured. Its not fear mongering, and its not for profit.
Many of these security consultants you speak of are not consultants at all, but experts working on this stuff in their free time for the betterment of the internet.
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.
Do you even know what DNSSEC is? It is nothing he is trying to sell, it is him trying to completely take care of the flaw he found in DNS last summer. A flaw that could have seriously fubared the net if he didn't go through massive patching with internet providers and large companies. So you know, just about all DNSSEC software is opensource, meaning it is free. He isn't a conartist and it is pretty ignorant to call him one, he spent countless hours last summer trying to get the patch out which he didn't make money off of since he released it for free.
You don't host anything for real paying customers do you? Let me give you a summary of how interaction with "security consultants" usually goes:
1. Customer gets cold called or sees some FUD on local TV, or portscans or the "consultant" has some dude in Malaysia digging around to find the sites hosted for pennies an hour. 2. Customer gets bilked out of a couple hundred dollars for a 'security audit' (a scan using a common tool with default settings usually) 3. Customer fails to understand any of it. 4. Passes a
Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?
Since Dan Kaminsky is active in this thread, I'd love to see him answer this question. I'm guessing he's probably bound by non-disclosure agreements and can't give us any details, but I'd like to know if he's seen succesful, real-world attacks out "in the wild" that resulted in real damage done.
The DNS cache poisoning attack was used the same week it was put into metasploit on a Verizon DNS in Texas where the attacker was forwarding people to a fake Google page with malware on it. Just one I can recall from when this first came out.
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.
Trust me, I'm raising more hell than you can imagine about the deployment issues of DNSSEC. Here's the truth:
1) You don't actually need to do all that resigning stuff. When best practices involve increasing your costs 100x, something is wrong. 2) You don't actually need to have your signatures expire. 3) You don't actually need that cron job. 4) They fixed that zone walking problem with NSEC3. If you have online keysigning, which I expect everyone to have, you don't even need that. 5).org is signed..com is coming, as is the root itself. Things have changed.
Standby. Seriously, this is coming, and it's not going to be miserable by the time you actually need to deploy it.
The flaw is really in DNS - the only authentication field in a DNS request is a 16-bit query id, plus the implicit authentication of a 16-bit port number, and IIRC correctly you could also birthday-attack the query-id. Kaminsky's changes to DNS implementations such as BIND (which was build into djbdns etc. since the beginning) get you a few more bits of protection against an attack, but that just means that DNS is "still pretty weak" as opposed to "really really weak".
And unfortunately, IPv6 DNS is no better - it keeps the same basic header for compatibility, adds some new longer record types, and adds some 128-bit addressing, but the QueryID's still the same old 16 bits.
DNSSEC gets to the root of the problem, with cryptographic signatures on the data. It may be overkill compared to just putting in a 128-bit or 256-bit Query-ID field, but basically it's something that's possible actually get deployed, because it's a set of additional data transported in DNS, not a replacement for DNS's transport protocols. The reasons it wasn't done years ago have a lot to do with the NSA/FBI anti-crypto policies of the 90s, and Verisign's reluctance to do a huge amount of work nobody cares about to protect.com, but we're finally getting the root signed.
No, it really is about securing your assets, instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing.
It's a matter of the scope of the attack. Any resolver (including your ISP's caching nameserver) can be the target. It wouldn't make much sense for an individual's resolver (their PC) to be the target--first of all, it's hard to get them to query for thousands of requests. Second, your payoff is small--you got one machine to think that ns1.example.com resolves to your IP address.
The real target is any caching server that lots of people use. It's much easier to get these to make requests for lots of subd
Optimistic guy (Score:4, Funny)
Kaminsky is incredibly enthusiastic about DNSSEC. ... to the point where someone not too knowledgeable (like I am) wonders if DNSSEC really is that amazing or if he was just high.
You just think that way because you haven't been.. (Score:5, Insightful)
.. hit yet.
Security is a tricky thing. You say security people sell you things "you don't need". But if you wait until you NEED security, it is already too late because you have a breach.
Security is not an ER visit, it is a regular preventative exam with your physician. It is something you have to take a pro-active approach with. Yes, this oten means investing time and money in something that has no immediate ROI. But that is the nature of the problem you are dealing with.
Parent
A: because it breaks the flow of a message (Score:4, Insightful)
Parent
Re: (Score:3, Interesting)
Re:Optimistic guy (Score:5, Informative)
(This is Dan)
DNSCurve can't achieve end-to-end security while still caching. Without the former, you're trusting the name server at Starbucks not to be malicious. Without the latter, there's a 10x (minimum) increase in DNS traffic and the internet collapses.
There's some really interesting math going on, but operationally DNScurve isn't a good path.
That being said, there are some really interesting things from DNScurve we can integrate into DNSsec without any code mods. Key rollover is a mess in DNSSEC, and it's somewhat unnecessary.
Parent
Re: (Score:3, Interesting)
Re: (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.
Re: (Score:2)
Huh?
DNSSec doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because you can't do DNSSec from a stub resolver and have to use TSIG (which protects the client->server data transfer, not the zone data).
DNSCurve doesn't let you set your laptop's DNS to Starbucks' NS and be safe, because DNSCurve protects the client->server data transfer (of each step of the process) not the zone data.
You're screwed either way.
Or, you can decide to either use a different resolver somewhere on the interne
Re: (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 DNS
Re: (Score:2)
The one difference is that in most cases the recursive resolver will be under the control of either the user themselves or the owner of the network. Eg., home computers implement stub resolvers talking to the nameserver included in the home router, which does the DNSSEC. You have to trust the server the stub resolvers are talking to, but that server's the little box sitting on the shelf above your computer instead of some random nameserver several hops out under the control of someone you don't know. Or you
Re: (Score:2)
Just look at Mr. Moller and his wonderful new car!
Re:Optimistic guy (Score:5, Informative)
(This is Dan)
Well, I was one of the guys who was wrong (about DNSSEC, anyway) so it doesn't completely match up.
Look, simple question: Do you think the existing system, of X.509 certificates, of SSL CA's, of private PKI's, is at all working? I sure don't. All I see are crappy passwords everywhere, being left as default, getting leaked, being brute forced, etc. Most security technology isn't working.
DNS works well. Seems to me more things should work like it.
Parent
Re: (Score:2)
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.
Parent
Re: (Score:2)
I guess what I am asking is this: such a failure that results in corrupting a DNS name is already bad enough. Would it not be worse if many other security mechanisms also depended on it?
What makes DNSSEC better than using protocols (such as SSH) which can independently verify the identity of a host by
Re: (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 sys
None of it as implemented is about security (Score:2)
I don't, IMO they are just a way for Verisign and Friends to collect toll.
But I don't see how DNSSEC fixes that at all, it just makes it easy for Verisign et all to collect yet more toll.
If people were really interested in security they would have the https cert stuff behave a bit more like ssh does, e.g. if the browser notices the cert for myfavbank.com has changed, and now signed by
Re: (Score:2)
Have a look at the Firefox Perspectives add-on, it's meant for telling you when a self-signed cert changes, but can also be configured for use with normal certs.
Re:None of it as implemented is about security (Score:4, Insightful)
You can get wildcard certs. for HTTP as well. They cost lots and lots of $$$
You wonder how much getting a domain signed is going to cost... thing Verisign is going to turn down a cash cow that big? I'd be surprised if they charge less than $1000 per domain.
Ultimately, as Verisign signs the root, all paths (and all money) leads to them - and that's why they're pushing DNSSEC so much.
Parent
Re: (Score:2)
Personally, when i type google.com into a resolver, I kinda like to get one of the IPs google wants returned for it, and not an IP the ISP or a hacker wants returned for it.
See, it's boring people like you who take the fun out of web surfing. Down with DNSSEC!
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:Need DNSSEC tools (Score:5, Informative)
(this is dan)
Yeah. This is being worked on. By the time the root is signed, you should have much more at your disposal.
Parent
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: (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: (Score:3, Interesting)
Thank you! (Score:2)
Thanks, Sam, I appreciate your taking the time to keep us annoying users informed!
Re: (Score:2)
Wow, an acronym explained (Score:2)
Wow an acronym explained was explained in a slashdot story posting... "DNSSEC (DNS Security Extensions)". Oh, the DNS part wasn't :)
Yeah, I know its a very common acronym.
I don't wanna put a subject. (Score:2)
Http has absolutely no security at all built into the protocol. It is all hacked together with cookies and the server remembering sessions etc.
The protocol itself is dumb. Make a request... get a response, thats it. Any security is on top of that.
If there was a standard for secure HTTP, all of these gimmicks and schemes could be removed from the hundreds of web frameworks and implemented in the browser / http server.
Re: (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 certi
Re: (Score:2)
That isn't what the original poster meant by security. Encryption only secures the transport, that does not mean SSL and TLS secures HTTPS from any exploits.
Re: (Score:2)
Well, SSL/TLS can, with the proper use of certificates, secure the endpoints against impersonation attacks. If, for instance, the browser has the server's certificate directly in it and won't accept any others, then it doesn't matter if the attacker can redirect the traffic to their server and forge DNS perfectly, the browser will still reject the server because it doesn't have the certificate the browser expects. Ditto the other way using client certificates. An attacker would have to compromise the endpoi
Re: (Score:2)
This is actually one of the things I'd love to see if DNSSEC actually does get going for real.
I'll love to be able to put SSH pub-keys and SSL(https) pub-keys in a verifiable DNS.
At this point tooling, etc. really needs to be improved if I'm going to implement DNSSEC on my domains.
The whole key-rollover stuff is still to complicated.
Dumb Question (Score:3, Insightful)
But since I don't claim to understand DNSSEC I'll ask it: how secure is DNSSEC against abuse by governments?
Re:new security products and services? great. (Score:5, Insightful)
Better than generating fear to reduce the rights of your citizens...
Parent
Re:new security products and services? great. (Score:5, Insightful)
Sincerely,
Both Political Parties.
Parent
Re:new security products and services? great. (Score:5, Insightful)
The Kaminisky bug is real, and its being used out in the wild. This is not a hypothetical academic exercise. DNS needs to be secured. Its not fear mongering, and its not for profit.
Many of these security consultants you speak of are not consultants at all, but experts working on this stuff in their free time for the betterment of the internet.
Parent
Re:new security products and services? great. (Score:5, Informative)
This is not how the kraminisky bug works. You can intercept and redirect traffic with a properly formed DNS label to a legitimate site.
Parent
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.
Parent
You obviously have no idea what your talking about (Score:5, Informative)
Parent
Re: (Score:3, Insightful)
Let me give you a summary of how interaction with "security consultants" usually goes:
1. Customer gets cold called or sees some FUD on local TV, or portscans or the "consultant" has some dude in Malaysia digging around to find the sites hosted for pennies an hour.
2. Customer gets bilked out of a couple hundred dollars for a 'security audit' (a scan using a common tool with default settings usually)
3. Customer fails to understand any of it.
4. Passes a
Re: (Score:2)
Aside from a few articles here and there, the "real world exploits" for this stuff, where someone actually gets harmed... well, where are THOSE reports?
Since Dan Kaminsky is active in this thread, I'd love to see him answer this question. I'm guessing he's probably bound by non-disclosure agreements and can't give us any details, but I'd like to know if he's seen succesful, real-world attacks out "in the wild" that resulted in real damage done.
Re:You obviously have no idea what your talking ab (Score:5, Informative)
Parent
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.
Parent
Re: (Score:2)
Re:You obviously have no idea what your talking ab (Score:5, Informative)
(This is Dan)
Trust me, I'm raising more hell than you can imagine about the deployment issues of DNSSEC. Here's the truth:
1) You don't actually need to do all that resigning stuff. When best practices involve increasing your costs 100x, something is wrong. .org is signed. .com is coming, as is the root itself. Things have changed.
2) You don't actually need to have your signatures expire.
3) You don't actually need that cron job.
4) They fixed that zone walking problem with NSEC3. If you have online keysigning, which I expect everyone to have, you don't even need that.
5)
Standby. Seriously, this is coming, and it's not going to be miserable by the time you actually need to deploy it.
Parent
It's really in DNS - BIND etc. were workarounds (Score:5, Informative)
The flaw is really in DNS - the only authentication field in a DNS request is a 16-bit query id, plus the implicit authentication of a 16-bit port number, and IIRC correctly you could also birthday-attack the query-id. Kaminsky's changes to DNS implementations such as BIND (which was build into djbdns etc. since the beginning) get you a few more bits of protection against an attack, but that just means that DNS is "still pretty weak" as opposed to "really really weak".
And unfortunately, IPv6 DNS is no better - it keeps the same basic header for compatibility, adds some new longer record types, and adds some 128-bit addressing, but the QueryID's still the same old 16 bits.
DNSSEC gets to the root of the problem, with cryptographic signatures on the data. It may be overkill compared to just putting in a 128-bit or 256-bit Query-ID field, but basically it's something that's possible actually get deployed, because it's a set of additional data transported in DNS, not a replacement for DNS's transport protocols. The reasons it wasn't done years ago have a lot to do with the NSA/FBI anti-crypto policies of the 90s, and Verisign's reluctance to do a huge amount of work nobody cares about to protect .com, but we're finally getting the root signed.
Parent
Re:new security products and services? great. (Score:5, Informative)
(This is Dan)
No, it really is about securing your assets, instead of trying to deploy yet another magic box that conveniently fails just as you try to get it out of testing.
Parent
Re:Is DNSSec really needed? (Score:4, Informative)
(This is Dan)
Too many exceptions, like www.facebook.com's low TTL, or CNN's non-response to nonexistent names, etc.
Parent
Re: (Score:2)
It's a matter of the scope of the attack. Any resolver (including your ISP's caching nameserver) can be the target. It wouldn't make much sense for an individual's resolver (their PC) to be the target--first of all, it's hard to get them to query for thousands of requests. Second, your payoff is small--you got one machine to think that ns1.example.com resolves to your IP address.
The real target is any caching server that lots of people use. It's much easier to get these to make requests for lots of subd