Home / Blogs

An Authenticated Internet

Lauren Price

Discussions around DNSSEC are so often focused on the root, the attacks, what DNSSEC does and doesn't do and so on — and these are all valid and important points. But there is far less attention focused on the opportunities that will surface from an authenticated internet.

Before I jump into the opportunities, first let's go through some DNS basics.

At the heart of the Internet's web service is the domain naming system, referred to as the "DNS". The domain naming system or DNS is like a phone book. Working with that analogy, let's say you decide that you want to call "Lauren's Lollipop Shop", but you don't know the number. You grab the phone book and, using the name, you get the phone number, and then you make the call.

The DNS works in much the same way. You know the name of website "lollipopshop.org", but you don't know the "number" (in computer-speak, this would be the IP address). When you type in www.lollipopshop.org, the phone book (the DNS) provides the lookup, and then your computer "dials the number" by going to the website.

The current problem with the DNS is that when it looks up a "number" for you, a group of bad guys can insert a different phone number into the phone book, one which pretends to be "Lauren's Lollipop Shop". When the bad guys answer the phone you assume it's the lollipop shop and give your critical information, such as your credit card information, to order 10,000 lollipops.

DNSSEC is a security measure that can help mitigate this risk known as domain hijacking also known as man in the middle attacks. DNSSEC digitally signs answers to DNS lookups using public-key cryptography. With DNSSEC in place, the bad guys can't lead you astray, because you won't be misdirected by them.

Now let's ask ourselves, what opportunities can surface when DNSSEC is deployed industry wide? DNSSEC is becoming more of a reality now — rather than a technical discussion which has been stuck in the mud for 15 years. We can now begin to think about new opportunities to build from a secure DNS, opportunities that build on the certainty that you have arrived at the correct website. Today, you can't be sure.

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.

Let's look at some opportunities for the technologies we use today:

  • SSL – There are standards for storing certificates in the DNS. With DNSSEC it would be possible to put these certificates in the DNS and to facilitate validating them by looking up other certificates in the certification path in the DNS. This could simplify maintenance of certificates from a user point of view since you would no longer need your local certificate cache, although it would place greater reliance on a robust and secure DNS.
  • VPN – It has long been noted that with DNSSEC it would be possible to setup VPN systems where encrypted tunnels could be setup as needed. Multiple options exist for storing the security parameters needed for a VPN to a site in the DNS at the domain name for the site. With DNSSEC a user could have high confidence in the security parameters and use them to setup an encrypted tunnel with the site.
  • Email – Forged email messages? DNSSEC can be used to authenticate email accounts. It can help each of the protocols that are using the DNS to support their efforts to add security to email by ensuring authentic information from the DNS is available to them. These include DKIM, SPF, and others. Email is probably the most common attack vector so by authenticating where the email came from makes this method of attack much more difficult. DNSSEC will make it possible to build email systems that confirm that email really is from the sender it purports to be from. Perhaps this will be another tool that developers will leverage in the mitigation of spam and email phishing attacks.
  • VoIP – Thinking outside the box here and in terms of ENUM, imagine if every VoIP user had a domain name. Using the DNS, one could lookup the phone number(s) of that user. With those phone number(s) one could lookup the IP address of the VoIP phone for that number. With DNSSEC each of these lookups would be guaranteed to be correct, and thus you would know you are contacting the person that you looked up. Of course there's more work to be done on the details of such a system, but you get the idea.

What are all the real world applications that can benefit?

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. What new applications can be built with this new landscape? Are there cost savings on the horizon which would curtail our current mind-boggling spend on online security? What else?

Considering the enormous amounts of private and critical data that is kept online, you want to be 100% certain of who is at the "other end of the line" — or in between for that matter. Today you cannot be certain, but with DNSSEC, you can gain a better level of trust. Let's now focus on the opportunities and the new wave of secure applications that can be built on an authenticated internet and a stronger more reliable DNS.

By Lauren Price, Sr. Product Marketing Manager, .ORG, The Public Interest Registry. Lauren Price also contributes to the .Org weblog located here.

Related topics: DNS, DNS Security, Security

WEEKLY WRAP — Get CircleID's Weekly Summary Report by Email:

Comments

Email encryption Jeff Six  –  Sep 28, 2009 6:25 PM PST

Along similar lines to what is mentioned above, this makes near-transparent (to the end user) email encryption possible. 

Good summary of how this would work here: http://bit.ly/QnqRJ

DNSSEC fairy dust The Famous Brett Watson  –  Sep 28, 2009 6:46 PM PST

This is one of those articles that needs a counterargument because it overstates its case. This won't be a thorough rebuttal: I'm just going to pick the low-hanging fruit.

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.

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, or tamper with your communications (other than to cut off communications completely). DNSSEC provides very little in comparison.

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-Thank you all for your comments! Lauren Price  –  Oct 02, 2009 7:15 AM PST

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 Michael Hammer  –  Oct 02, 2009 9:46 AM PST

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, Lauren Price  –  Oct 05, 2009 9:33 AM PST

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 Michael Hammer  –  Oct 05, 2009 10:34 AM PST

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.

Not withstanding that other attacks are possible in the circumstance described, DNSSEC does not prevent the bad guys from leading you astray (your general assertion). It is not a DNSSEC problem, it is a problem of an overly broad assertion as to what protection DNSSEC might afford someone if implemented.

As far as asserting that a system thrown into a wood chipper is a hardware failure, One might also claim that getting struck by an asteroid causes headaches.

Mike

Initial Foothold Dan Kaminsky  –  Oct 06, 2009 1:43 PM PST

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.

A large, complex solution to a non-problem The Famous Brett Watson  –  Oct 05, 2009 8:17 PM PST

What DNSSEC does do is make it much harder for someone to use a DNS-based MITM attack.

The DNS has been openly vulnerable to such attacks since day one. MITM attacks are popular with cryptographers, because that's the kind of attack that cryptography addresses. In actual practice, MITM attacks aren't an issue because attackers generally find it simpler to compromise the endpoints than the middle. All the technical expertise is concentrated in the middle of the network, so it tends to be the most secure part, and the part most quickly fixed when compromised. To the extent that MITM attacks exist, they tend to be conducted by the actual service providers in the name of "network management". Your service provider can thwart DNSSEC if it wants to, either by using a downgrade attack (removing signatures) or by offering false assertion of validity (if you are silly enough to trust your ISP).

So tell me, Lauren, which real-world MITM attacks (cite examples) would DNSSEC protect against, which can not also be thwarted by much simpler non-cryptographic mechanisms? If this is DNSSEC's great advantage, then illustrate it in terms of real-world benefits, not theoretical ones.

mitm attacks that dnssec protects against Paul Wouters  –  Oct 07, 2009 5:31 PM PST

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.

Brett, any third party on which you James Galvin  –  Oct 08, 2009 7:20 AM PST

Brett, any third party on which you rely for security can "attack" you, so saying that an ISP can thwart DNSSEC is not a new vulnerability. It's can be mitigated by doing your own DNS lookups rather than depending on your ISP but, then again, I don't think the risk of an attack from your ISP is very high.  It's not zero of course so one would do well to choose their ISP with some care (when you can).

Also, you suggested there are non-cryptographic methods for protecting against MITM attacks.  Could you give an example of one?

As far as DNSSEC and MITM attacks are concerned, what LP said is that DNSSEC would make it harder to conduct MITM attacks, not that DNSSEC would protect against all MITM attacks.  DNSSEC protects against cache poisoning.  DNSSEC provides assurance that you know where it is you need to go.  This is an excellent complement to TLS/SSL which provides the confidential channel for communication (see for example http://www.circleid.com/posts/securing_a_domain_ssl_vs_dnssec/) and includes the MITM protection as it relates to the DNS among other things.  Although, have you seen the null prefix attacks against TLS/SSL (http://www.thoughtcrime.org/papers/null-prefix-attacks.pdf)?  It seems even TLS/SSL is potentially vulnerable to a MITM attack.

Security needs new and better tools in order to keep up.  DNSSEC is another tool in the chest.  That's the most important point in this article in my opinion.

I don't think the risk of an The Famous Brett Watson  –  Oct 08, 2009 10:20 AM PST

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

Maybe not an intentionally malicious attack, but every now and then some executive gets inspired by the SiteFinder stunt and starts forging DNS results for profit. I'm not sure what the current tally is in that regard, but it's more than a theoretical possibility.

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

I didn't mean to suggest that. I was just guarding against attack scenarios which aren't really MITM attacks, such as most cache poisoning attacks. I want to see scenarios where the cryptographic content of DNSSEC is an essential ingredient, not superfluous complexity.

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

SSL/TLS provides confidentiality and identity verification through signed certificates. The identity verification part already renders DNS cache poisoning ineffective (unless you can compromise the identity verification, of course). For more detailed comments, see that other CircleID article to which you referred, where I am also commenting.

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

No, it's vulnerable to buggy implementations and bad practices, both of which are real problems. The buggy implementations are being dealt with as issues are discovered, although it's clear that not all software providers are equally fleet of foot in that regard. The bad practices might get a little attention too, given the current media spotlight. I can only hope so.

DNSSEC is fortunate because, as the new kid on the block, it has yet to tarnish its reputation with such real-world shortcomings. Optimism triumphs over experience for now.

You didnt read my previous commentsSSL/TLS providers Paul Wouters  –  Oct 08, 2009 10:24 AM PST

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.

That's a practices issue The Famous Brett Watson  –  Oct 08, 2009 6:06 PM PST

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.

# 27 Reply (max. reply level reached)  |  Link  |  Report Problems
Brett, this is a reply to you Dan Kaminsky  –  Oct 08, 2009 6:27 PM PST

Lets just continue all replies as in this thread.

OK, Brett, I think we've hit it.

You think the problems with SSL are out of scope.  We see them as fundamental consequences of a technology that can't delegate (meaning all trust has to chain to one of a few points, as opposed to being carved out to responsible parties) and can't exclude (meaning the security of the entire system is equal to that of the CA with the weakest practices).

You can't fix SSL with better practices, unless you can fix those practices everywhere.  Good luck with that!

SSL needs a better way to authenticate public keys, than X.509 can provide.  DNSSEC is that way.  We like SSL!  We just think its backed into a bit of a corner with its X.509 dependency.

# 28 Reply (max. reply level reached)  |  Link  |  Report Problems
Also, you suggested there are non-cryptographic methods James Galvin  –  Oct 09, 2009 8:24 AM PST

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

I didn't mean to suggest that. I was just guarding against attack scenarios which aren't really MITM attacks, such as most cache poisoning attacks. I want to see scenarios where the cryptographic content of DNSSEC is an essential ingredient, not superfluous complexity.

Are you suggesting that cache poisoning is not a MITM attack? If that's not what you're saying then I don't understand you're comment. DNSSEC ensures that the data is authentic and thus makes it impossible to poison a cache for a signed domain in a validating resolver, i.e., a MITM attack is thwarted. The cryptographic content of DNSSEC is essential.

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

SSL/TLS provides confidentiality and identity verification through signed certificates. The identity verification part already renders DNS cache poisoning ineffective (unless you can compromise the identity verification, of course).

I disagree, as others here have also stated. The identity verification depends on the quality of the certificate, which depends on the certificate issuer, and this question is relevent for the entire certificate chain. More importantly, the certificates used are basing the identity in part on the domain of the site it is identifying (in the most common usage which is certificates for web browsing). Thus DNSSEC and TLS/SSL work better together than separately.

Also, I'm not convinced that DNS cache poisoning is ineffective in the presence of certificates. Of course you're going to ask me to prove it, which I'm not prepared to do at this time. Phishers use https protected sites. The question is how they got the user to the phished site. Perhaps someone more knowledgeable than I will have something to say about this.

MITM The Famous Brett Watson  –  Oct 09, 2009 5:18 PM PST

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

Yes: most cache poisoning is effected by exploiting bugs in DNS implementations, not by intercepting and modifying traffic between DNS clients and servers. I think our difference here is a semantic one: I only classify an attack as MITM if the actual attacker is positioned to intercept and modify traffic between the communicating parties, but I can see why there might be some ambiguity, since a poisoned cache lies between the ultimate DNS client and the authoritative nameserver. An intermediate nameserver with a poisoned cache is not an attacker; a hostile intermediate nameserver would be a MITM attack.

While it's true that DNSSEC would in principle thwart cache poisoning no matter how it is effected, DNS already thwarts cache poisoning in principle for all but MITM attacks. It fails to do so in practice because of bugs, and to some extent because of design deficiencies which limit the amount of entropy in the query (a flaw which can be fixed without resort to complex cryptography).

I'll let the rest of your comment stand on its own merits.

# 35 Reply (max. reply level reached)  |  Link  |  Report Problems
Brett, contact me Dan Kaminsky  –  Oct 10, 2009 12:07 AM PST

Brett,

You've visibly avoided enough of the arguments in this thread that I'd like to talk to you voice.  Please mail dan@doxpara.com so we can set this up.  Note, this isn't to harangue you or anything.  I'd just like to have a more rapid back-and-forth.  Remember, I used to have your position on all this.

# 36 Reply (max. reply level reached)  |  Link  |  Report Problems
In March-April 2005, users of an ISP Lauren Price  –  Oct 08, 2009 9:38 AM PST

In March-April 2005, users of an ISP had specific spyware, spam and pay-per-click trojans, from redirection sites

The ISP’s cache had hundreds of DNS names spoofed…

• AmericanExpress.com
• FedEx.com
• CitiCards.com
• DHL-USA.com
• Sabre.com

Source: Allison Mankin http://www.psg.com/~mankin/vita.txt

Try again The Famous Brett Watson  –  Oct 08, 2009 6:44 PM PST

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.

*shrugs* Dan Kaminsky  –  Oct 08, 2009 6:46 PM PST

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?

and Paul Wouters  –  Oct 08, 2009 7:19 PM PST

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.

# 31 Reply (max. reply level reached)  |  Link  |  Report Problems
No. The Famous Brett Watson  –  Oct 08, 2009 10:06 PM PST

You really want to argue cache poisoning hasn't happened in the field?

No, I want to argue that it isn't happening as the result of MITM attacks.

# 32 Reply (max. reply level reached)  |  Link  |  Report Problems
*sigh* Dan Kaminsky  –  Oct 08, 2009 10:18 PM PST

Brett,

Widespread deployment of DNSSEC would have stopped my cache poisoning attacks, MITM or not.  I would not have been able to have blindly spoofed responses and had them accepted.

Even with DNSSEC just on the root and the TLDs, I wouldn't have been able to have done things like hijack all of .com.

That being said, if all DNSSEC did was stop DNS cache poisoning, I'd say it was somewhat overkill.  DNSSEC provides a better way to key SSL, PGP, IPSec, and VOIP.  That's not unimpressive.

# 33 Reply (max. reply level reached)  |  Link  |  Report Problems
You sound like me Dan Kaminsky  –  Sep 29, 2009 12:43 PM PST

Brett,

You sound like I did during the whole DNS patching imbroglio.  Believe me, I was surrounded by DNSSEC'ers, and all I wanted was for them to shut up while we put the immediate fire out.  I promised them, lets finish this out, then I'll look at your toys.

Turns out, their toys are actually more useful than I thought.

So the piece you're missing is the fact that authentication is a huge, huge mess.  According to Verizon Business, when they actually dig in forensically to identify what happened during an attack, 61% of the time it wasn't buggy software but rather failed auth that let the bad guys win.  No passwords, bad passwords, shared passwords...in concrete, real world data, the inability to authenticate peers has proven itself to be one of the major threats driving exploitation today.

Shouldn't we have better than passwords?  Shouldn't we be able to use the CA system that's spun up around SSL/X.509 for client auth?  Well...that hasn't worked out very well, has it?  Something about hundreds of different root certificates and an explosion of complexity around interop.  Even the one area where X.509 works — SSL for HTTPS — there's maybe a million SSL endpoints on the internet.

Over half are self signed.

Look, I like SSL, I think it's a pretty good protocol.  But the trust system behind it just doesn't work very well.  It's horribly fragmented, you are always as insecure as the least secure root, and worst of all, you can't delegate.  That's right, unless you buy an intermediate certificate that allows you to sign for "www.bankofamerica.com" (something you can buy!), you can't buy a certificate that just lets you sign other certificates under "yourdomain.com".

But then, look at DNS.  There's not 100 roots, there's 1.  If your registrar is Network Solutions and your registry is Afilias, then GoDaddy and Verisign have absolutely no way to mess with your domain.  And delegation is at the heart of DNS's model.

See, DNS has been building scalable systems for every other protocol on the Internet for 25 years.  It's how we do business across organizational boundaries.  Security is the only thing that's had to eschew DNS, because the data it got out of it wasn't authenticated.

Security doesn't really work across organizational boundaries, now does it?

There's a lot of things we can put in the DNS, once DNSSEC gives us a reason to believe it.  We can't fix everything.  But can we make a serious dent in the 61% of compromises that happen because we have no idea who we're talking to?  Yeah, yeah we can.

Still sceptical The Famous Brett Watson  –  Sep 29, 2009 6:59 PM PST

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.

Appreciate the skepticism Dan Kaminsky  –  Sep 29, 2009 7:35 PM PST

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.

You're not addressing what I acutally said The Famous Brett Watson  –  Sep 29, 2009 11:37 PM PST

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

My first problem is that you are framing my objections as though they are a defence of SSL and other technologies over DNSSEC. They are not. My point, as I have stated twice already, is merely to show that the article over-states the case for DNSSEC. It also under-states the potential of SSL at one point, claiming that it does not do something which it does in fact do, and has done for years, in practice, daily. My second problem is that you are comparing "SSL as we find it in the real world" to "DNSSEC as deployed in an ideal world".

I'd love to engage in an interesting debate on the merits of DNSSEC versus other alternatives, and on the nature of the security problem in general, but I decline to do so here and now. It would be off-topic.

Comparison Dan Kaminsky  –  Sep 30, 2009 5:39 AM PST

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?

Regarding 1) see my post above. It Paul Wouters  –  Oct 07, 2009 5:40 PM PST

Regarding 1) see my post above. It does protect against compromised name servers and MITM

Regarding 2) you claim SSL is better because you have a third party verify your identity that's seperate from DNS. But in reality that's not the case, because most SSL certs are "verified" simply using email from the whois server going to the domains MX DNS record. So really, it's still just DNS. EVR might be a little better, but thats how SSL certs originally started too. EVR works because it is too expensive for normal people (security through money)

Regarding 3. If you are running a screen capture and key logger from a third party, all bets are off. Irrespctive of DNS(SEC) or SSL. DNSSEC does not make this worse.

Part of the internet architecture is missing Karl Auerbach  –  Sep 29, 2009 10:14 PM PST

I agree with Brett comments on the fact that the primary article is wrong when it says that DNSSEC provides "certainty that you have arrived at the correct website".  (I will skip my normal reaction when someone equates the internet with the much smaller thing called the world-wide-web.)

DNSSEC only means that you got the name-to-DNS-record mapping that the owner of a domain "zone" wants you to get.  DNSSEC says nothing regarding the correctness of that mapping.

The internet architecture is missing a very important layer - that of mutual identification and authentication.  In human life when we make a phone call we do not trust the phone companies to connect us to the number we dialed, we know that we and the phone companies make mistakes.  So we engage in a bit of initial mutual identification and authentication - we say who we are or we recognize one another's voice, etc.  The software we use on the net doesn't usually do this.

We have drops and splatters of that layer in things like SSL, SSH, and other, usually crypto-based, mechanisms.  But we don't have anything that is unified.

Part of the problem is technical - identification and authentication are hard.  But harder still are the mechanisms - the key distribution mechanisms - to disseminate the nuggets of critical data.  Those have to handle asynchrony, accidental or intentional loss, mis-ordering, or replay of transactions.  And people do mess up, machines do fail, and backups are used to restore machines back to prior states, thus making it necessary for there to be security prone repair mechanisms.

But the biggest problem is the one about who gets to to be king of the internet - whoever controls the ultimate truth of identification and authentication holds a great power over the net and its users.  There are answers, mainly answers that avoid the issue of mapping a "who" on the net to a particular living, breathing person but that, instead, tend towards mapping a "who" to a particular something that has acquired a reputation on the net.

There is another lurking problem of DNSSEC - and that is that it needs to exist with non DNSSEC.  DNSSEC contains several protocol inflection points that I predict will be mis-implemented, under tested, and serve as foundations for attacks.

Hehe Dan Kaminsky  –  Sep 30, 2009 5:51 AM PST

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.

Stub resolvers David A. Ulevitch  –  Sep 30, 2009 6:04 AM PST

Will there be growing pains?  Sure.

Dan — But in the absence of DNSSEC-aware stub resolvers (which would make them full-blown resolvers, a side-effect I support wholeheartedly), how do you expect DNSSEC to ever make an impact for end-users?

Nefarious resolvers and MITM could simply answer that a zone is not DNSSEC-enabled and the stub resolver or forwarding resolver (or any downstream resolver) wouldn't be the wiser. Because unless ALL zones are DNSSEC-enabled, and the resolver is configured to discard ANY non-DNSSEC-signed records, it will have no choice but to listen to the response.

Or maybe I misunderstand this chicken and egg problem with DNSSEC…

(btw, really good thread and why I love circleID)

Hehe Dan Kaminsky  –  Sep 30, 2009 1:47 PM PST

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.

Already had the egg, time to eat the chicken Jay Daley  –  Oct 05, 2009 3:15 PM PST

But in the absence of DNSSEC-aware stub resolvers (which would make them full-blown resolvers, a side-effect I support wholeheartedly), how do you expect DNSSEC to ever make an impact for end-users?

A better way to think of it is a stub resolver + a validator.  All the validator does is validate, it does not change the resolution function.  So having the a "DNSSEC-aware stub resolver" does not make them full-blown resolvers.

Even if a client has a local stub-resolver and transparently uses a remote validator (i.e. the stub-resolver is non-DNSSEC aware and uses a DNSSEC-aware forwarding resolver) then there is a benefit if:

1. The channel between the stub-resolver and the validator is secure; or

2. The only way the stub-resolver can resolve is through a resolver + validator pair (yes I understand this still has weakness if the channel is not secure and security is only as strong as the weakest link etc, but this is still better than no DNSSEC); or

3.  The stub-resolver can choose to resolve through a resolver + validator pair (working on the principle that something is better than nothing).

I expect many enterprises will start with 2 believing they have done enough on internal security (IDS, firewalled VLANs etc) to believe they have roughly achieved 1.  All implemented centrally and without DNSSEC-aware stub resolvers.

Eh Dan Kaminsky  –  Oct 06, 2009 1:44 PM PST

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.

Yes, all end nodes will have to Paul Wouters  –  Oct 07, 2009 5:44 PM PST

Yes, all end nodes will have to run DNSSEC themselves, using forwarders as caches.
Really, this is not different from HTTPS, where browsers do the crypto to verify the SSL certificate based on preloaded CA's.

With a signed root, you'd only have to have one key (as compared to a few hundred CA certs in the HTTPS world)

You cannot discard DNSSEC records. This stripping is detected because of the parent's DS record.

At most you can do a DOS attack, bu any MITM can do a DOS attack by eithering filtering your input, or by spamming it.

To post comments, please login or create an account.

Related Blogs

Related News

Topics

Industry Updates – Sponsored Posts

Join Paul Vixie & Robert Edmonds at the Upcoming Distinguished Speaker Series

Q3 2014 DDoS Trends: Attacks Exceeding 10 Gbps on the Rise

LogicBoxes Announces Automation Solutions for ccTLD

3 Questions to Ask Your DNS Host About DDoS

Introducing Our Special Edition Managed DNS Service for Top-Level Domain Operators

Afilias Partners With Internet Society to Sponsor Deploy360 ION Conference Series Through 2016

Neustar to Build Multiple Tbps DDoS Mitigation Platform

The Latest Internet Plague: Random Subdomain Attacks

Digging Deep Into DNS Data Discloses Damaging Domains

New gTLDs and Best Practices for Domain Management Policies (Video)

Nominum Announces Future Ready DNS

New from Verisign Labs - Measuring Privacy Disclosures in URL Query Strings

Video Interviews from ICANN 50 in London

DotConnectAfrica Delegates Attend the Kenya Internet Governance Forum

3 Questions to Ask Your DNS Host about Lowering DDoS Risks

Continuing to Work in the Public Interest

Verisign Named to the OTA's 2014 Online Trust Honor Roll

4 Minutes Vs. 4 Hours: A Responder Explains Emergency DDoS Mitigation

Dyn Acquires Internet Intelligence Company, Renesys

Tips to Address New FFIEC DDoS Requirements

Sponsored Topics

dotMobi

Mobile

Sponsored by
dotMobi
Minds + Machines

Top-Level Domains

Sponsored by
Minds + Machines
Afilias

DNS Security

Sponsored by
Afilias
Verisign

Security

Sponsored by
Verisign