-
Website
http://www.matasano.com/log -
Original page
http://www.matasano.com/log/754/a-case-against-dnssec-a-matasano-miniseries/ -
Subscribe
All Comments -
Community
-
-
Top Commenters
-
Popular Threads
All Comments
What if we widely deployed DNSSEC? Would that fix these problems?
It would fix some, but not the most significant, of the security problems. If DNSSEC could be widely deployed, it would be harder for attackers to forge records. However, DoS attacks would still be possible, as DNSSEC also relies on the same static nameserver hierarchy as legacy DNS. It might actually be easier to launch DoS attacks with DNSSEC, as the servers have to do more work in response to queries. Most DNSSEC implementations rely on online secrets, so a compromised host would lead to compromised records and redirection attacks similar to the ones described above. DNSSEC would certainly increase DNS name resolution latency, exacerbating the performance problems mentioned below. And it would not help with dynamic updates.
I don't think it's a question on whether DNS needs to be more secure or not. DNS has security problems. CoDoNS is one answer to most these problems. DNSSEC attempts to solve one problem well, and it does solve that problem - but at a huge cost. DNSSEC is not the solution we're looking for. But I'd argue that we do need a new DNS
DNSSEC never claimed to prevent phishing attacks. phishing is a name space issue not a data correctness issue.
You keep claiming that applications should add their own security. DNSSEC does that for the DNS. Remember the DNS is a application in its own right. SSL and IPSEC are not good fits at this level.
DNSSEC is optional. You don't have to run DNSSEC aware applications or DNSSEC aware nameservers. If you don't
you are left with the same old DNS that you are used to.
Having run DNSSEC aware validating recursive nameservers and published DNSSEC signed zones. Including performing key rollovers etc. there isn't (won't be) much more work than there is today with plain DNS. You generate your keys. You sign your zone then you publish it by loading it into your nameserver. Next you pass the DS records to your parent zone in a similar manner as you pass your NS records today. You then just need to remember to periodically re-sign your zone.
I'll admit that it is a little more complicated today in that you need to actively publish your keys and collect
trusted keys. However this short term issue as the infrastructure zone providers get their acts together.
1. As far as the end-to-end principle goes DNS is an /application/. So for DNS to be responsible for its own security is precisely the kind of action the end-to-end principle advocates.
2. Every other application relies fundamentally on DNS, including those that you cite - AIM or any P2P network. So long as DNS is insecure then any P2P network can be attacked via DNS. Your view that somehow P2P developers can go it alone without DNS is plain wrong.
3. DNS is one of those technologies where you can pick up the basics in five minutes but it takes years to master. Largely because it has been around so long that plenty of introductory texts exist. DNSSEC does not have these introductory texts and so to someone of limited technical skills may seem daunting. However it is not terribly complicated and when the introductory texts are available that will become clear.
The argument that DNS is an application seems so silly that I don't even know how to address it. If DNS is an application, then so is ARP, RIP, OSPF, BGP, PIM-SM, and the Spanning Tree Protocol. The word has no meaning.
Of course DNS isn't an application. It's a piece of infrastructure, used exclusively as a building block for actual applications.
I'll address the rest of these points in subsequent posts. Obviously I think they're crazy talk.
Mark Andrews, thanks for the reasoned and measured response. I'm not going to earn any politeness or courtesy with my arguments.
http://securitytracker.com/alerts/2007/Jan/1017...
http://cve.mitre.org/cgi-bin/cvename.cgi?name=C...
http://xforce.iss.net/xforce/xfdb/28745
http://www.securityfocus.com/bid/22231/discuss
Wasn't I just making the point like a week ago that security extensions shouldn't be re-engineered into protocols unless a) they reduce the attack surface of its implementations, not increase it and b) the circumvention of the security mechanism outweighs the practicality of exploiting it.
Interesting that one of those advisories is an SSL advisory. Oh, wait, that's right they're using SSL to handle the RSA key negotiations. Oops. So now not only are our web architectures having their attack surface increased by being reliant on the successful implementation of supplemental security extensions, but now we want DNS implementations to be as well.
Isn't the fundemental rule of secure development that you want to give the attacker the fewest possible exposed points of failure to exploit?
Tom makes at least 3 excellent points is this post:
1) PEBKAC: We have SSL certificates to authenticate web sites, if end users are already falling for accepting bad SSL certs supplied by a MITM; what makes you think they won't accept similar bad DNS messages supplied by a MITM.
2) Infrastructure is not where you fix problems that exist in the implementation of application layer services: Application developers shouldn't be so lazy as to force their applications to implicitly trust DNS information. gethostbyname() isn't something to build a host-based authentication system around, nor should it be.
3) Ends don't justify the means: You go through all the effort of generating RSA keys for all of your DNS servers, then you have to inform the underlying resolution architecture on all the platforms you have deployed what the trusted servers are. After all this, you still haven't prevented localized DNS tampering. What about local HOST file resolution? Is that just going to go away? Are we going to start validating host file entries via DNS... Doesn't that defeat the purpose of having them? If all of these attack vectors are maintained, where was the value add of building DNSSEC into the architecture?
My take on the solution to this problem is this:
If you need a cryptographic solution for verifying endpoint authenticity, don't use DNS. Use SSL, and and a private CA for issuing certs to clients with validated credentials, it's what it was designed to do. Don't try to build a cryptographic extension into an already insecurely designed protocol. It's like Adam Sandler throwing the newspaper on the pile of puke in 'Big Daddy'.
I'd also like Jay to explain to me why P2P networks need DNS... Is he insinuating that it's not possible to architect a P2P network without using DNS, that seems a bit naive.
And yes, the emotion I'm trying to evoke with "IETF people instead of the market" and arguing whether DNS is an application is, "profound, unpleasant concern".
About 7 years ago I started a company with Dave Meltzer and Danny Dulai doing streaming media delivery over a multicast-routed overlay network. A couple other companies did it better (like FastForward) and we got crushed, but I got to pay attention to what people said to them: "you can't do multicast at the application layer! It's a gross layering violation!".
I'm really bothered by the thought that the IETF is populated by people who think that the OSI model --- again, O S I, people --- is the Talmudic kernel of protocol design. So that something is an "application" if it uses BSD DGRAM sockets to communicate, but "infrastructure" if it's hooked up directly to software interrupts in the kernel.
Leave aside the notion that the OSI model doesn't capture the Internet stack well: if you divide the world up into "transport, infrastructure, and applications", "infrastructure" is "anything you build on AND never use by itself". DNS is infrastructure. You could replace it and, as long as you didn't break libresolve and whatever the hell Win32 uses, nobody would *ever* notice. Just like I don't care how you reinforce the concrete in my building but I do care about how my desk is built. Infrastructure, applications. NOT HARD.
I feel bad being a dick about this because Mark Andrews took the time to write a polite response, without evoking the "I'm from the IETF, and what RFCs have YOU written" sentiment that Jay did. Mark is clearly more important than Jay and I'm casting aspersions on both of them. Oh well, omelettes, broken eggs.
Anyway, back to the technology:
It's easy enough to tell the difference between an application and infrastructure. Does it normally run on a router on an end computer. That's why the routing protocols you list are infrastructure and DNS is an application.
You even say yourself that people use DNS as a building block for applications - more proof that it is an application. The only applications that are built using RIP, OSPF etc are specialist network applications. To all other applications they are completely invisible - a sign of true infrastructure.
Nobody is saying that applications should leave security to DNSSEC. Also nobody is sayin that DNSSEC verifies endpoint security. All it does, as you should expect, is secure DNS.
Host file entries don't need validating because you put them there. DNSSEC is about securing messages you receive from other people.
All DNSSEC does is let you verify that the DNS data you receive is the DNS data that was sent to you. It makes no assertions about the endpoints.
On the P2P point:
OK, with some effort you can avoid the direct use of DNS entirely. You can write your own name resolution protocol and to bootstrap the network discovery you can define some well known IP addresses in your application and ensure they always respond.
But seriously though, who is going to go to all that trouble? The name resolution side, sure some people do that, but the bootstrap as well?
I was wrong to say that people can't write P2P without DNS. It is more correct to say that people /don't/ write P2P without DNS.
Can you take another cut at what differentiates "infrastructure" from "application"? You've put DHCP firmly in the "application" category. Also, ARP.
It's obviously not "computer" vs. "router".
Maybe it's "desktop" vs. "server"? I totally buy that. Of course, that leaves DNS in the infrastructure.
Either way it seems pretty obvious to me that DNS is not an application. In that nobody sits down to "use" DNS.
When someone writes an application they use gethostbyname or the equivalent. So DNS is not transparent to them. Routing protocols like RIP are entirely transparent unless they are writing network specific applications.
The test works pretty well.
On the P2P side my point was that any P2P app that wants to be free of DNS /must/ do two things
- its own name resolution
- its own non-DNS bootstrap
Yes some apps do the first but almost none do the second. So they do rely on DNS somewhere.
Disregarding the RFC and how the IETF may think about this, my test to determine if X is infrastructure or not is simple and maybe a bit naive, I ask myself: does the Internet work without X? If the answer is no then X is part of the infrastructure otherwise X is not part of the infrastructure.
The need for DNSSEC and all its relative complexity arises when we start considering Internet support at lower levels of layering for the kind of message we call money in all its potential forms, with DNSSEC directly providing the kind of directory we call bank and payment accounts so that a future payment can be routed between the correct accounts. Here the cost of doing this directly supported by DNSSEC will potentially be much less than the current cost of an online Visa or Paypal transaction supported by TLS/SSL and all the traditional banking protocols that sit on top and which typically cost merchants 6% of the transaction value and which are not economical for payments of less than $5.
In my understanding it is possible to get this cost down to the point where every payment of a bus fare or supermarket coupon is an almost zero cost Internet message. The main cost of this will become the manual effort of checking your monthly statement, which getting everything online will help you to automate to an extent. However, this requires a more inherently secure directory than DNS in its current form.
Even having said that: if CA's charging $30 for BER bits bugs you --- and it bugs me too --- then the problem to solve is getting a trusted, secure "public" CA. That's not a technical problem.
With DNSSEC it becomes possible to design directories which are secure enough to be used for monetary identities for everyone - not just merchants who can jump through all the hoops currently involved in setting up a merchant account.
This is because with DNSSEC the certificates will delegate through the domain registration process. If the syntax differs between
my_account_number@example.bank and my_account_number.example.bank the semantics don't as example.bank obtains it's certificate from the .bank TLD key and my_account_number obtains its certificate from example.bank . The syntax and semantics of the certificate chain are crucial if there is any possibility of identity being misread i.e. phishing. Also we can expect the .bank TLD to be a lot more careful about certification than .com , and consequently it's certificates will be trusted to a much greater extent and rightly so.
So I think that DNSSEC does solve a genuine problem, though the cost of it doesn't justify being applied to applications that don't need it, until the development cost has been carried by those that do to the point where scale and further technical development makes DNSSEC cheap enough to improve other directory applications.
I'm going to be away from the Net for a week but will check back then.
I'd like to see you do 15,000-25,000 SSL-enabled web transactions per second on a single machine with just one CPU. I've seen nameservers that can do that many authoritative queries per second. Add SSL/TLS to that mix, and the number will drop -- by orders of magnitude.
And many of the most important nameservers are already vastly overloaded by the crap they've got to deal with today.
Personally, I think we can solve a lot of the DNS security issues by simply requiring (and enforcing) good administrative principles whereby we enforce a separation between the authoritative and caching-only functions, and we carefully vette the incoming traffic to only allow those types of queries and transactions that we know to be "safe".
DNSSEC is useful and serves a purpose, but I don't think that cache poisoning/pollution and phishing are the right problems to be trying to use it to solve. Those can be solved in other ways, leaving us to use DNSSEC to solve harder problems in other areas.
DNSSEC gets in the way. It distracts us from real problems that need to get solved. It also substitutes a bunch of IETF people for the judgement and expertise of the market, which actually has a track record in solving security problems. Some of the loudest IETF participants have no qualifications other than willingness to spend time on mailing lists and at conferences.
1. Most security staff make a point of being distracted from solving real problems. If it wasn't DNSSEC it would be something else.
2. The security market is ineffective - see the economics and security literature.
3. Arguments need to be judged by something better than loudness.
- DNSSEC is way past its need-by time.
- It will be an addition that very few applications/services use/require.
- Companies will try to market their crappy products on the back of DNSSEC.
But if they could find a good use case for IPSec (VPN) then why not see what happens with DNSSEC? I agree that it is totally redundant and that any problem could be solved without using DNSSEC.