LP-Thank you all for your comments! I really enjoyed the discussion. DNSSEC is a security measure that can help mitigate this risk known as domain hijacking also known as man in the middle attacks. Probably the only thing that DNSSEC protects against is DNS cache poisoning, which is a kind of domain hijacking. You can also hijack a domain name by compromising the domain administration process, such as by phishing for passwords, installing keyloggers, etc. DNSSEC can not do anything about these kinds of hijack attacks. Similarly, DNSSEC is of limited value when there is a genuine man in the middle (MITM). Internet service providers are ideally positioned to conduct MITM attacks, and many have tried to "monetize" through creative MITM attacks involving DNS forgery. Sadly, DNSSEC isn't going to solve this—at least not until it is completely ubiquitous. LP-I said DNSSEC can help “mitigate” I did not say it "completely stops" or anything matter-of-fact. DNSSEC is a method to combat one form of the attack vector. Will you be able to fully trust SSL and VPNs? Today, they cannot be trusted with certainty. SSL and VPN are past the point—they check to make sure that the website is real once you've already gotten there. DNSSEC ensures you get to the right place. I consider this to be the most egregious error in the article. It is completely back-to-front in its analysis. DNSSEC can not ensure that you get to the right place: it can only certify the name-to-address mapping. It does nothing to ensure that your packets are actually going where you address them, and if MITM attacks are a serious concern, then this is a problem. SSL, on the other hand, can tell you whether or not you have arrived at the correct destination. SSL is robust against MITM attacks, and was always intended to be so. Under the protection offered by SSL, a man in the middle can prevent you from reaching your intended destination, but he can not impersonate that destination, eavesdrop on your traffic with that destination, ortamper with your communications (other than to cut off communications completely). DNSSEC provides very little in comparison. LP-What you say here is true, but I was speaking in terms of the DNS. DNSSEC ensures that the DNS query you perform has been answered within the chain of trust. As Dan mentioned, while SSL is great once you get to a site, they lack the chain of trust. DNSSEC and SSL are different clubs in the security bag. Yes, you should still use SSL. Yes, you should still use VPNs. Yes, you should still refrain from clicking on malware, etc. I did not say these other security measures should be replaced by DNSSEC. The point is - you should use DNSSEC as well. Ideas that come to mind are: healthcare records online; trusted online financial transactions; more efficient ways to communicate and conduct commerce, government and social interactions. Good grief. Add a sprinkling of cryptography, and suddenly the Internet is a safe place for everything? Wake up and smell the botnets. The Internet is populated with a vast number of end-user computers which have been actively subverted by organised crime networks. Cryptography of this sort is supposed to secure communications against threats in the network, not threats in the endpoints. Practically speaking, DNSSEC isn't going to make anything noticeably safer for anyone, simply because it's not addressing the major threat. It's not even related to the major threat. LP-I did not say that DNSSEC is the “security silver bullet” and should replace all other security measures on the Internet. I simply listed the types of electronic communication that can benefit from DNSSEC. The Internet is still a dangerous place - caveat surfer. What DNSSEC does do is make it much harder for someone to use a DNS-based MITM attack. The only way to make the Internet safer is to peel the attack onion, and DNSSEC works on one layer of skin.

LP-What you say here is true, but I was speaking in terms of the DNS. DNSSEC ensures that the DNS query you perform has been answered within the chain of trust. Is what you wrote really true? A very similar statement was made at the DNSSEC meeting during RSA in April. I asked how DNSSEC would do this if the (client) endpoint was compromised. The speaker corrected themself and agreed that DNSSEC would not ensure that the DNS query performed would be answered within the chain of trust. Don't get me wrong, I think DNSSEC is a worthwhile approach. I simply have a feeling that it is being oversold and this will inevitably lead to disspointment on the part of some implementors/users. Mike

If an end user's system is compromised, then everything is inherently insecure on that system: account information (username / passwords), identity and sensitive information (documents, email), services (DNS, email, IM, www, skype), and even down to devices (keystrokes, scanners, other devices on the network). This is not a DNSSEC problem, it's a security policy and implementation issue. DNS lookups secured with DNSSEC will also fail if the end user's system is thrown into a wood chipper, but that's a hardware failure :-)

Lauren, I absolutely agree with you on the nature of attacks that are possible if an end user machine is compromised. One of those attacks involves the ability to misdirect users to servers other than the intended destination based on reliance on DNS. Hence my comment with reference to the statement in your original post

With DNSSEC in place, the bad guys can't lead you astray, because you won't be misdirected by them.

Michael, If your system is already compromised, DNSSEC won't stop it from being compromised. If your system isn't, however, DNSSEC can maintain your defenses, by dropping the cost of strong peer authentication by orders of magnitude. Don't believe me? Imagine if all we had to work with were host files. Is DNS not orders of magnitude less expensive to manage -- for simple routing -- than those? I see similar comparisons between X.509 (which hasn't scaled, we all know it) and DNSSEC. With 61% of compromises provably sourcing from authentication faults, a significant reduction of weakly authenticating systems -- not through guilt, but through cost reduction -- would be significant.

the simple cases, which we see in the wild now too, are compromised authoritative name servers and compromise recursive name servers. Since DNSSEC guarantees the authenticity of the data, and the private keys for signing are not on any name servers, a compromised name server cannot be used to inject false data.

I don't think the risk of an attack from your ISP is very high.

Also, you suggested there are non-cryptographic methods for protecting against MITM attacks.

This is an excellent complement to TLS/SSL which provides the confidential channel for communication...

It seems even TLS/SSL is potentially vulnerable to a MITM attack.

You didnt read my previous comments SSL/TLS providers provide identity verification solely through the MX record. It is completely dependant on DNS. It therefor in practise offers nothing more then DNSSEC can.

I did read your previous comments. They are quite good, and require research to answer, so bear with me. By "verification solely through the MX record", do you mean that certification authorities base their certification on the ability to receive an email? I think you'll find it's worse than that in some cases: I hear that some base their certification solely on their ability to receive payment from you. But this is not intrinsic to SSL/TLS: it's a practices issue. It can be fixed, in principle, without any change to the existing protocols or implementations. Whether or not it can be fixed in practice is largely a socio-politico-economic question that I'm not well placed to answer.

Are you suggesting that cache poisoning is not a MITM attack?

If you are referring to this incident, then the vulnerability was limited to specific bugs in specific DNS implementations, and it was a shameful indictment on those implementations that they were vulnerable to such an old exploit. It wasn't a man in the middle attack, and the vulnerability was closed by fixing the bugs, so your example doesn't meet the criteria I set.

Fine. How 'bout the enormous poisoning of China Netcom right after my talk, or the Brazilian attack that compromised something like 1% of Brazil's largest bank customers? You really want to argue cache poisoning hasn't happened in the field?

This happened recently in New Zealand too, ISP had a compromised name server. (this is why we need dnssec on the endnodes, as the next step) A few years ago it happened in Canada when the largest ISP's had bad cache for one of the top 3 Canadian banks. the only reason we do not see more cache poisoning, is that people will still click on www.randomnamemeaningless.com/hacked/yourbank.php and login.

It sounds to me like some of your optimism is based on the fact that DNSSEC hasn't had a chance to fail in the real world in the same way that SSL has. Battle plans rarely survive contact with the enemy, and DNSSEC has an unblemished record because it hasn't seen active duty yet. In any case, you don't seem to have offered a rebuttal to any of my objections. In fact, it's hard to summarise your key points and address them -- I've tried. Perhaps you'd care to form a clearer argument? I think that one of the things missing from your case is a statement of the threat model that DNSSEC addresses. This was present in the original article, and formed the basis of my rebuttal. To reiterate: 1. Article claimed that DNSSEC was good against DNS hijacking and MITM attacks. I pointed out that not all DNS hijacking involves cache poisoning, and that ISPs can and do conduct MITM attacks against DNS. Article over-states its case because it fails to acknowledge these limitations. 2. Article claims that DNSSEC "gets you to the right place", whereas SSL and VPNs do not. This is wrong: DNSSEC certifies name-to-address mapping, but can not certify (in and of itself) that you are communicating with the right party. SSL can establish a secure communications channel with a certified party -- assuming you can locate that party at all. In other words, DNSSEC points you in the certifiably-right direction, but SSL tells you whether you've arrived at the certifiably-right place. 3. Article waxes enthusiastic about all the sensitive data we can put online securely once it's protected by DNSSEC. I submit that this is ridiculous, because it ignores all the (very real) threats unrelated to DNSSEC. A malware-compromised computer renders all the benefits of DNSSEC void, and malware is rife. None of this means that DNSSEC is without value -- only that its worth is seriously inflated by this article. There is a separate question as to whether DNSSEC is a good idea in and of itself -- whether there were, perhaps, simpler and more effective ways to achieve the same security goals. I don't want to open that can of worms -- at least not here and now.

Seriously, I do appreciate the skepticism. You have no idea how weird it is to be on this side of the argument. I think your problem, fundamentally, is that you think things work better than they actually do. SSL and VPN's are wonderful technologies, *if* they have authenticated their endpoint. The data is not subtle on this: They often don't. Of the only 1M SSL endpoints on the Internet today, only about half have valid certificates. Even with just a million, already a pittance, half straight up offer no security value! And that's the best we have, that's when the browser straight up errors on a bad certificate. Mike Zusman of Intrepidus went ahead and looked at VPN clients. You know how much they care about bad certificates? By default -- not at all. And VPN's are barely even technologies that have to work cross-organizationally! It's no either/or, Brett. It's not that we use SSL *or* VPN. It's that SSL and VPN *both* become able to authenticate their endpoints at dramatically less cost, because adding trusted key material becomes no more difficult than adding the address that brought the connection in the first place. Do you see the symmetry there? The same system that gets you there, tells you what to expect -- as opposed to the present architecture, which has to build some completely alien chain that never quite worked in the real world. Are there other threats? Absolutely. You're not at all wrong about the problem of compromised endpoints. But when we actually look at the compromise data, we see in no uncertain terms that 61% of compromises come from failed authentication. The report is here and I invite you to take a look: http://www.verizonbusiness.com/resources/security/databreachreport.pdf SSL and VPN struggle because it's too expensive to acquire certificates. Smartcards and other technologies that could very well eliminate passwords flounder, because they flat out do not work across organizational boundaries. But we *know* how to make things work across organizational boundaries. Bootstrap off of DNS! That's how HTTP does it, how SMTP does it, how LDAP does it...and it just works, right up until the point that we want crypto. Then suddenly, mysteriously, it always becomes a mess. I argue it becomes a mess because we abandon DNS too early. If DNSSEC has any chance of letting us finally, *finally* make smartcards and other similar technologies scale across organizational boundaries, then it will directly address 61% of the compromises Verizon Business is seeing. The key is to make security orders of magnitude less expensive to deploy. I know you want simplicity. But are you going to to tell me X.509 is simpler than anything in the known universe? I do think DNSSEC will be radically mutated by contact with the enemy. For instance, it will have to become far easier to deploy. Turns out that almost all the messiness of DNSSEC just comes from the root not being signed. You have to admit, there's some part of you that totally digs there being one root that's been around for 25 years, instead of a hundred roots that beg and plead their way into the browser. But without the value from the one root, nobody's been writing the necessary code to make DNSSEC deployable. I wouldn't say this if I wasn't absolutely positive: DNSSEC can ultimately be made almost as easy to deploy as my own port randomization patches. That doesn't mean my patches were easy, but they were manageable and didn't require babysitting. All DNSSEC designs that require babysitting will never see production. I also think we'll see DNSSEC evolve to be far more of an end-to-end solution. Frankly, our endpoints are much smarter now. If we can have an embedded SSL stack, we can certainly have an embedded DNSSEC stack. This will handle much of the messiness around ISP MITM. But it's all for naught, until the root is signed. So, lets sit back and get that done.

I think your problem, fundamentally, is that you think things work better than they actually do.

Ah! But you hit the nail on the head. You say I am comparing SSL in the real world to DNSSEC in the ideal world. But I say that DNSSEC has a very good reason to look like it will work in a more ideal manner: DNS itself has 25 years of proven history as a strongly delegated, strongly exclusionary, centralized root architecture that *works*. It delegates -- I interact, once, with the naming layer above me, and then I own my space. It excludes -- I can keep the vast majority of badly designed operations out of my risk space. It has a centralized root, derived partially from the state system, that is effectively incorruptible. Remember, for a small amount of money and a "I promise to be good", you too can go out and buy a universal certificate from a Certificate Authority. I'm serious, the cost of an SSL cert that impersonates you, me, and every bank on the planet is actually manageable. The CA's had to do this because without it, private CA's wouldn't interoperate. It works, but I wouldn't call that security. Lets look at the four technologies in the original article, and see how well they're working today: SSL -- Many endpoints, but half are self-signed, and the other half are only as secure as the least secure CA VPN -- Most clients don't validate certificates Email -- PGP works only to a small number of geeks, S/MIME a checkbox feature VoIP -- Works great! If you use Skype. Otherwise no crypto. I'll throw in a fifth: Smartcards -- Occasionally available inside an organization. Totally unknown on the larger Internet. Here's the bottom line: Do you think things are working well today, or not? We've been doing what we can for years. Do you think it's enough? Should we stay with this status quo of trying to scrape X.509 into a workable authentication base, or should we try to leverage this other system (DNSSEC) that has worked great for 25 years?

I think it was proved rather conclusively that, if you control DNS, you are king of the Internet, controlling the ultimate truth of identification and authentication, *today*. How do you think you get an SSL certificate? It sends you an email, which uses DNS. Oops. A lot of the DNSSEC debate is colored by frankly naive arguments on the pro side. For example, there was a plugin for Firefox that told you if the website you connected to had its IP address validated by DNSSEC. Cute trick, but no security value -- there are many layers one can be attacked, simply knowing the name-to-IP mapping is good isn't something to raise to the user. It is true DNSSEC is a fix for cache poisoning attacks, that is rather better than simply 13-16 bits more entropy. But it's also true that DNSSEC would be horrible amounts of overkill if that was the only problem it could solve. What changed my mind was seeing that it wasn't. We can host much, much more inside of DNS than just name-to-IP mappings. We can host public keys that bootstrap trust. DNS is a delegated namespace. That means, among other things, that it's not our place to decide what other people host inside of it. HTTP was designed for mostly static content too -- we saw how that worked out. DNS already is a unified layer for locating resources outside our organizations. When we need to send a mail, who tells us what mail server? When we need to make a VoIP call, who tells us where the SIP gateway is? When we need to SSL or VPN somewhere, how do we find our server? DNS is always there, as a unified layer, to guide us there. It just, right now, can't tell us what to expect when we arrive. If there is going to be a unified layer anywhere, 25 years of the tech actually working says DNS is where it's going to be. DNSSEC just puts key material alongside the existing, well-proven system for locating assets in an application-independent manner. It's not that big a change! Will there be growing pains? Sure. But "I predict will be misimplemented" is sort of a dick thing to say, and I'm just going to call you out on it.

Will there be growing pains? Sure.

The web was supposed to be mostly static documents, with *occasional* special case "CGI binaries" that would dynamically generate data once in a while. Didn't turn out that way. Create a delegated environment and a really useful protocol, and everything from all-dynamic-all-the-time web pages to Web Services was inevitable. I see similar with DNSSEC. It wasn't designed for smart stubs, but create an environment where for the first time we have a canonical, delegated, exclusionary worldwide trust infrastructure, and end-to-end code *will* materialize. This will happen because of a decade of failed scalability promises from security product vendors. When I say smart stubs, I mean it too. The stub will know the root key. It will chain validate. It will even validate the cut between secure zones (the root and probably the TLD) and non-secure zones (most second level domains). There are ways of doing this that utilize the caching layer (OpenDNS) or, if a device is just too simple, can choose to trust it. There hasn't been pressure to develop these ways, however, because there's been no return on this investment. That's changing. The resolution of the chicken and egg problem is to recognize that the leap of faith is the root being signed. Given this semi-public action, a return on investment by private entities becomes feasible. Part of that investment is sanding down all the rough corners of DNSSEC. If there are secure records to be gotten, an ecosystem will grow to acquire them -- *if* it's better than the status quo. It can only be better if the root is signed, but when it is, wow, authentication becomes so much easier for so many protocols.

We'll see what happens once the root is actually signed. I actually do expect to see full blown resolvers, when end-to-end trust is required.