Kaminsky On DNS Bugs a Year Later and DNSSEC 127
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:new security products and services? great. (Score:5, Insightful)
Better than generating fear to reduce the rights of your citizens...
Re:new security products and services? great. (Score:5, Insightful)
Sincerely,
Both Political Parties.
Re: (Score:1)
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.
Re: (Score:1)
The "Kaminsky bug" is a hoax. Kaminsky didn't discover anything. The only thing that Kaminsky can put his name on is the hoax. In my NTIA comments
http://www.ntia.doc.gov/dns/comments/comment027.pdf [doc.gov] I traced down everything Kaminsky claimed to have discovered to find the true author.
There are no (or rare) "Kaminsky exploits" in the wild. All servers but BIND have implmented UDP port randomization for years. WITHOUT port randomization, one can exhaust the 16bit of Query ID in 65000 spoofed UDP packets--if o
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.
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.
You obviously have no idea what your talking about (Score:5, Informative)
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.
Re: (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,
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.
Re: (Score:2)
(This is Dan)
To be fair, I don't see much of a difference between NXDOMAIN and SERVFAIL except possibly impact on negative caching. Stuff doesn't work.
DNSSEC planners have been way, way too willing to let things break in order to protect non-critical features. DNS is not allowed to just return SERVFAIL. Luckily, the protocol itself is flexible enough to allow much more stable deployments.
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)
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: (Score:2)
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.
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.
A: because it breaks the flow of a message (Score:4, Insightful)
Re: (Score:2)
If /. didn't have this inane length limit on the size of a comment tile that dates back to the silent era, I would not have to do that.
Re: (Score:2)
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.
Not only that, but if you invest and it actually works, you get the impression you wasted money, because nothing happens. :P
It's the same thing with Global Climate Change. If we actually fight it tooth and nail, the best we can hope for is no change from the present. Hardly a reward! ;)
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.
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)
DNSSEC has two big problems:
1. Without an unbroken chain of trust to the root, it's worthless. Self signed DNSSEC is no better than no DNSSEC.
2. It's vulnerable to MITM attacks - just strip the DNSSEC information from the returned packets and return a normal (modified) DNS reply.
3. Because of the chain of trust setting it up will cost $$$ - probably going to Verisign, as usual.
4. Until absolutely everyone in the world uses DNSSEC the fallback to normal DNS cannot be removed, so 2. remains a problem. 3. gu
Re: (Score:2)
Oh and I'd add the thing is f..ing *hideously* complex to setup, with multiple competing implementations that aren't compatible with each other because some have special DNS tags, some use TXT records, the formats keep changing, etc. Spent 4 days on it once.. I got maybe 10% of the available dnssec testers to even recognize that I implemented their brand of dnssec.
Re: (Score:2)
(This is Dan)
1) Agreed. I'm not very popular in some DNSSEC circles because of it :) But yes, the entire Trust Anchor Repository thing is a mess. That's why it's so important to get the root signed.
2) With the root signed, you always have a trusted path that says if a given domain has DNSSEC or not. If it does, stripping the DNSSEC won't matter, you'll know there's *supposed* to be signatures there.
3) Because DNSSEC delegates, it's not really amenable to the sort of tricks that have cost money in the pa
Re: (Score:2)
A "validating stub resolver" will actually need to be (basically) a recursive resolver itself (it needs to do multiple queries to verify each signature in the delegation chain from the root down to the record it's actually interested in). And thus, if you want it to perform well, it'll need a local cache.
Now it's basically a caching recursive resolver.
So, is your claim that because the caching recursive resolver which you run on localhost can use a second-level remote cache instead of talking to the authori
Re: (Score:2)
(This is Dan)
Estimates on cache hit rates in DNS are about 90% -- meaning for every query that hits a server, ten queries got chomped in a cache.
I'm uncomfortable asking the Internet to increase their DNS query capacity by 10x. DNS has a performance curve where once it dies, it dies kind of catastrophically. 10x increases are asking for trouble.
Re: (Score:2)
...not to mention that DNSCurve requires per-query crypto on the server, while DNSSEC does not (by a design that really, really wants to allow offline key signing). Curve25519 is fast but it's not *that* fast.
Re: (Score:2)
Your statistic would be valid for no cache vs a cache.
But that's not the actual question at hand.
The question is:
What's the cache hit rate for a recursive cache serving a group of machines, vs. the cache hit rate for a recursive cache serving just a single machine.
I'm going to place my bet on nowhere near a 10x increase in traffic from having an unshared local cache.
But I haven't done the test. If anyone wants to (or knows of literature that's already explored this)...
Re: (Score:2)
See here [dempsky.org], about crypto CPU usage.
I'll also note that DNSCurve lookups use less network bandwidth than DNSSEC. DNSSEC drastically increases network bandwidth requirements with all those individual record signatures that need to be returned...
Re: (Score:2)
(This is Dan)
The point is that we can actually share DNSSEC responses across multiple nodes, not just a single node, using the existing framework. Yes, we will need clients that *can* go straight to the root. But they won't *have* to, which is a neat design element of DNSSEC.
Keep hitting me here though, maybe we can find a problem!
Re: (Score:2)
(This is Dan)
It is true that DNSSEC increases aggregate bandwidth.
I'm not sure about the DNSCurve numbers right now, given that the implementation I've seen can only do about 5,000 encrypt/decrypts a second on hardware that'll do 15,000 DNS responses a second.
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:1, Insightful)
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.
I guess it depends if you care about getting the correct IP address back when resolving a host or not.
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.
To each their own thou!
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!
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.
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.
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:2)
Actually, when a nerd starts using his personal desktop experience as a rebuttal to a large-scale engineering problem, you know the logic car has just driven off into the weeds.
Put another way--how would you like to be the guy who does "two mouse clicks" for, say, the Hotmail email servers? (If you so much as mention using a Perl script to handle it I will r
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: (Score:2)
(This is Dan)
If I get a cert for www.doxpara.com from a CA, I need to get another cert for mail.doxpara.com, foobar.doxpara.com, and so on (assuming I want one private key per server).
If I acquire doxpara.com from Verisign, I can handle the rest myself thank you very much.
It's a pretty major difference.
Also a major difference is the reality of who can screw you. In DNSSEC, you have to worry about your registrar (GoDaddy), your registry (Verisign), and the root. In x.509, you have to trust every CA in the
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.
Re: (Score:2)
(This is Dan)
I don't see Verisign really being in a position to "stick it" to the states that control ccTLDs or registry's that control various gTLDs (org, info, etc). And while Verisign will in fact be able to place toll on names under com and net, they're in the competitive position of needing to be reasonable compared to org, info, and other domains. This is exactly analogous to the position Verisign has on .com and .net today, as they're the exclusive registry for those TLDs. If you don't like .com/.
Re: (Score:2)
Go to Firefox,Tools,Options,Advanced,Encryption,View Certificates,Authorities. Pick the cheapest CA there who will do what you want[1], and you're set.
But don't forget, you still end up having to pay them every year or so, it doesn't matter that they are crap, you still need to pay toll to somebody. You yourself
Re: (Score:2)
(This is Dan)
Excellent, excellent questions. This is the sort of stuff I was asking before I switched sides on the DNSSEC war.
The problem with SSL is it doesn't matter if *you* aren't paying a worthless CA; as long as a worthless CA is out there, he can corrupt every domain, everywhere. That sucks. So SSL becomes a matter of finding the least secure CA possible and compromising that.
Things are different in DNSSEC. Because of delegation, the root is the only entity with absolute power over everyone -- an
Re: (Score:2)
But the fix for SSL is not about fixing the CAs, it's getting the browsers to behave more like SSH (or better). Then at least the browser will give useful warnings for a change, that'll help people who really care about security. While it won't help the "click through" users, nothing much will help those against attackers anyway.
Then that's the way it should be - YOU decide who you want to trust, with the help of technology.
In contrast with DNSSEC, you're stuck with Verisign for .com.
_Someone_else_ decides
Re: (Score:2)
(This is Dan)
Yes, because browsing securely should look like UAC, with every new site throwing a prompt in your face as if you had enough information to go on.
No. We can, and need to stop imagining the user is some sort of god that can accurately judge risk of accepting unknown keys (or worse, keys 'recognizable' with some arbitrary sequence of hexadecimal characters). This is a lie we're telling ourselves, and I'm done with it.
You're right that Verisign controls .com. Guess what, they control it *today*
Re: (Score:1, Interesting)
How much network traffic will DNSSEC add to the network?
Minimal network traffic, except if you're root/com (Score:2)
DNS doesn't take up a lot of network bits - at the beginning of a data flow, you typically look up a DNS name to find the IP address, then start doing things, and even if all you're doing is a small text email or fetching a small text html page, the protocol headers alone are a lot bigger than the DNS query, and usually the data's a lot bigger. Changing to DNSSEC adds a few hundred bytes to that query, but it's almost always a drop in the bucket.
Of course, if you're a big name server, like one of the root
Re: (Score:1)
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.
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:1, Flamebait)
Considering you can't be bothered to read the information out there to even understand it, I think you'll find it very hard.
Its not actually hard if you use someone elses encryption libraries, but if you are too lazy to even lookup how it works, and its fairly clear you have no understanding of how it works, its probably safe to say you are going to consider it hard.
In reality, its not really a any worse than say adding SSL support to a web browser.
Re: (Score:2)
Re: (Score:1)
And, since you're too lazy to post links to DNSSEC howtos (like this one [dnssec.net]), you're not helping and only name calling. The issue is that there are 15 RFCs with DNSSEC in the title [rfc-editor.org] and no clear idea where to get started.
But, hey, this is Slashdot, where any idiot can get a lame name like "BitZream", and post insult anonymously.
No worries; I will email Dan and talk to him offline about it.
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:1)
Re: (Score:1)
I was very pleased to see this discussion taking place in an open forum, and would loved to have had the opportunity to follow it. I regret you've taken your interaction offline.
I myself have been a DNS administrator (among other things) since the original implementation. I remember converting from host tables wasn't particularly fun at the time.
Re: (Score:3, Interesting)
Thank you! (Score:2)
Thanks, Sam, I appreciate your taking the time to keep us annoying users informed!
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.
Is DNSSec really needed? (Score:1)
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.
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
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.
Re: (Score:1)
Yes. But the us govt could do that before. DNSSEC doesn't enable this.
DNSSEC only enables a false sense of security that it wouldn't happen, while leaving the man-in-the-middle attack ignored and vulnerable.
There are basically two kinds of attacks: Man-in-the-middle (MITM) and blind attack which cannot see responses. UDP Port randomization makes blind attacks quite nearly impossible, and this has been known since 1999 or before. TCP DNS makes blind attacks impossible.
If the attacker is in the middle, it d
Re: (Score:1)
Well, to be fair, the US govt has waged two wars against countries Iraq and Afganistan, and did not interfere with their domains. There are some lines that are technically possible to cross, but aren't likely to be crossed. It would create a lot of diplomatic fallout to alter domains.
The only case I can think of where it might be a real problem is the case where there is a government in exile that requests changes to their country's domain that harms the de facto government in the country.
However, one thing
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?
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.
Re: (Score:2)
Your suggestion just gave me the piss-shudders.
A lot of people are
Re: (Score:2)
Why should it be hard? We're not talking about getting a CA-signed certificate verifying identity here, it's a self-signed certificate to insure that only the person who created the account accesses it. Prompt for a couple of things like name, generate and sign and add to the appropriate certificate stores for use. Assuming you're not just reusing a certificate you've already generated. This should be trivial, it's just that the toolmakers (browser makers, etc.) don't bother with proper support for more tha
Re: (Score:2)
And then:
I think you answered yourself.
The Web works because it has very low friction. Having to play idiot games with certificates and managing them adds tremendous friction. That you don't seem to see this suggests you haven't thought very carefully about the consequences of such a system, if at all.
The reason why DNSSEC seems to be su
Re: (Score:2)
That's the thing, though: it shouldn't need to add significant friction. There's no games to play, and minimal management that ought to be needed. It should be about as complicated as keeping track of the credit cards in your wallet, which seems to be well within the realm of the majority.
Actually UI is a real problem for DNSSEC (Score:2)
Some parts of the DNSSEC process invite clean UI connections - setting the keys, running human-oriented query tool, etc. It's far easier if you include registering the key as part of the process of registering the name, of course. But that's not how most people use DNS.
So you type a URL into your browser, and the browser hands it to a a resolver client, and the resolver client does a query. With Vanilla DNS, if the query fails, the client tells the browser it fails, and the browser either gives you so
Re:I don't wanna put a subject. -OK, house analogy (Score:1, Insightful)
That's kind of the point. Dan has found a flaw in the basement of your house.
The entire house is in jeopardy, no matter how well built. Every house affected.
Do you :
A: Call Kaminsky a damn liar, denounce his snake oil, sip your turpentine.
B: Stucco and paint every 10 days, whistling to yourself forcefully.
C: Try to jackhammer out the flaw and form up some new foundation meantime
D: Nuke the house from orbit, start from scratch, total web tech re-over in IPv6
I think Dan proposes C and eventually D. Mos
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?
Somewhat secure - everything's in the open (Score:2)
Nothing's perfect, but the DNSSEC signature process is mostly out in the open - you can see the public keys for the name servers, and you can check the signatures on the keys for yourself, and you can also get yourself domain names almost anywhere in the world if you don't like a given registrar/registry. So while a government _could_ probably bully a registry into signing a forged certificate for your domain name, it would at least be publicly visible that "your" key had changed.
Also, the government foot-
Re: (Score:2)
> So while a government _could_ probably bully a registry into signing a forged
> certificate for your domain name, it would at least be publicly visible that "your" key
> had changed.
That's not what I meant. I was wondering how easily they could manipulate it to gain additional control over the Net.
Kaminsky/Vixie DNS Scam Known as Media Hack (Score:1)
I think my comments to the NTIA on DNSSEC hit the point on Kaminsky and the DNS scam. As others pointed out, this is a group of shysters. MIT's "Technology Review" picked up the "Media Hack" aspect of the Story in December. That article is a good read if someone has a link.
Here are my NTIA comments which detail the Kaminsky/Vixie scam aspects and expose problems with DNSSEC:
http://www.ntia.doc.gov/dns/comments/comment027.pdf [doc.gov]
One of the things not detailed in my NTIA comments is that Kaminsky tells people t
Re: (Score:2)
> ...I could not get .ORG TLD officials to respond to questions about whether there was
> regulatory approval for their actions.
Are you saying that they may actually have done something *without permission*? Awful. Just awful.
Re: (Score:1)
The .ORG operator won't respond to the question of whether they had regulatory approval to carry out this action.
A Top Level Domain(TLD) is operated under the supervision of ICANN and IANA, just like the root DNS servers. So TLDs should should have permsission from ICANN & IANA (and so from the NTIA of the Department of Commerce of the US Govt)--again--just like the root DNS servers need approval. The NTIA requested comments on DNSSEC(which I responded to) but NTIA has not announced any authorization to
Re: (Score:2)
Absolutely true. However, the ability to delegate/federate security is such a powerful force for lowering the costs of proper design and management that making this one technical change will facilitate the operational strength you correctly call out.