Dept of Homeland Security Wants DNSSEC Keys

This is a big deal:

The shortcomings of the present DNS have been known for years but difficulties in devising a system that offers backward compatability while scaling to millions of nodes on the net have slowed down the implementation of its successor, Domain Name System Security Extensions (DNSSEC). DNSSEC ensures that domain name requests are digitally signed and authenticated, a defence against forged DNS data, a product of attacks such as DNS cache poisoning used to trick surfers into visiting bogus websites that pose as the real thing.

Obtaining the master key for the DNS root zone would give US authorities the ability to track DNS Security Extensions (DNSSec) “all the way back to the servers that represent the name system’s root zone on the internet”.

Access to the “key-signing key” would give US authorities a supervisory role over DNS lookups, vital for functions ranging from email delivery to surfing the net. At a recent ICANN meeting in Lisbon, Bernard Turcotte, president of the Canadian Internet Registration Authority, said managers of country registries were concerned about the proposal to allow the US to control the master keys, giving it privileged control of internet resources, Heise reports.

Another news report.

Tags: , , , , ,

Posted on April 9, 2007 at 9:45 AM • 60 Comments

Comments

Rich • April 9, 2007 10:03 AM

I hate to mention a hot topic, but this scares me a lot more than the possibility of not owning a gun.

It seems so hard to put ourselves in the shoes of others.

Since we are the leaders of the free world, why wouldn’t the world want us protecting and caring for the Internet? Anyone who doesn’t must have something bad in mind. Probably evildoers.

The world can trust us with nukes, but we can’t trust anyone else.

The people can trust us to only wiretap the guilty, why would we wiretap anyone else?

I just don’t get why anyone would have any concerns!!!

Brandioch Conner • April 9, 2007 10:04 AM

All non-US countries should now abandon the .com, .org, .net, etc TLD’s.

Maintain your own servers for your country domains (.uk, .us, .de, etc).

Which was how it should have been setup in the beginning. TLD’s do not scale.

Yes, I know. But what about big companies. Won’t they have to register their name in all those countries? Yes. They will. But they’re big companies. They should be able to manage it.

nedu • April 9, 2007 10:07 AM

Before anyone goes off half-cocked… How likely is it that the well-meaning folks at DHS just don’t have the faintest clue what DNSSEC keys are?

Isn’t it likely that the “cryptographic keys to the internet” sounded extremely valuable and enticing to someone whose mathematical education stopped after they took high-school algebra in college?

Nicholas Weaver • April 9, 2007 10:23 AM

Actually, it makes sense…

Without this, ICANN can be established forever as the sole-authority root for secure DNS’s PKI.

By forcing ICANN to disclose the key to the federales, the federales will be able to terminate ICANN’s contract in the future WITHOUT shutting down future name registrations.

avery • April 9, 2007 10:33 AM

Nedu, every time I’ve heard that the government doesn’t have the know-how or technology to do some heavy handed big brother-esque thing, it turns out that not only is the person telling me that wrong, but the situation is uglier than I would have guessed.

greg • April 9, 2007 10:39 AM

This still does not address any kind of IP spooffing attacks. Overall basic IP give almost zero guarante on where the packets come from.

I can’t really see any big advantage of DNSSEC without fixing the basic problem IP spoofing. As for which is the weakest link, I would say its a tie.

Paul Crowley • April 9, 2007 10:44 AM

I wonder how our use of the Internet will be affected if there’s a real tussle over the DNS root keys? There are the beginnings of a tussle, like TLDs valid in China but not elsewhere, but it’s possible to imagine much more serious instances of it. Especially when there’s so much money in being the root. What if a coalition of major websites (eg Google) and ISPs published their own root, or backed something like OpenDNS?

It might be the only way we can kill off centralized naming schemes and PKI for good…

Brenden Kuerbis • April 9, 2007 10:46 AM

FYI, the Internet Governance Project (http://blog.internetgovernance.org) launched a month-long series of blog entries on DNS security last week, focusing specifically on the problem of cryptographically signing the DNS root zone. We’ll explore some of the hidden and not-so-hidden political implications of this technical change. We will show how DNSSEC implementation, if handled properly, creates an opportunity to overcome some of the thorny global governance issues associated with the current root zone file management procedure. These postings — hopefully with the aid of your comments — will evolve into a new position paper on the politics and economics of DNSSEC to be released in May. The ideas will be discussed at the Symposium on “Internet Governance and Security: Exploring Global and National Solutions,” in Washington, DC, May 17, 2007. (http://internetgovernance.org/events.html)

Dept. Of SPOF • April 9, 2007 11:07 AM

How smart is it to implement and demand control of a single point of failure in a distributed system that was designed specifically to prevent the need for such vulnerabilities? By controlling the root keys, DHS would be painting a gigantic target on themselves – or at least putting a big chip on their shoulder and daring the rest of the world to knock it off. Perhaps there is also a certain element of wanting to be able to say that if the world doesn’t let them win the game the US will take it’s routers and go home.

This is just another case of DHS shooting themselves in the foot in the name of “securing the country”. This isn’t even security theater anymore – it’s security slapstick.

Jack C Lipton • April 9, 2007 11:31 AM

One thing that springs to mind is the use of the supervisory roles to “disconnect” sites that the US administration is not happy with…

Switching from the existing DNS structure, despite its security issues, to an “authoritarian” model where a strong central authority manages the name space is a move away from the useful aspects of internet anarchy…

Additionally, the whole argument of .com not scaling may be irrelevant in a world of multi-national corporations…

Hagai • April 9, 2007 11:40 AM

See: http://www.hbarel.com/Blog/entry0012.html

In brief:

  1. Someone has to hold these keys. Be it the DHS or anyone else.

  2. It does not make us or anyone less secure than we are now.

  3. DNSSEC is aimed at protecting against hackers, not against national espionage. If you do not expect, you are not disaapointed.

Måns • April 9, 2007 11:44 AM

First, a clarification:

Brandioch: Moving off .com does not help. It is the empty string domain after .com, ie. “.” that DHS wants the keys to. That point in the namespace encompasses the entire tree, be it .com or .se.

There are two reasons why DHS wants this.

First, DoD, together with NIST, has been very active in DNSSEC developement. The .MIL domain will probably be signed pretty soon. Pushing root signing forward is just a logical extension to this.

Second, since DNS is a very important piece of (security) infrastructure, DHS of course wants it. Make that “wants it” or “wants it secured” depending on paranoia level. Me, I’m just suspecting the old inter-agency turf war. Today, the root zone is managed by ICANN under a contract with DoC. Moving authority to DHS is just a parallel change.

General points:

Keep in mind that the track record of DoC in running the root has been impeccable; those that think it is plain wrong that USA runs the namespace should consider that.

The idea of creating several roots is very dangerous. The DNS is designed with one root in mind and tolerates parallellism badly. I have run company-internal roots. It is a nightmare. The Internet thrives on being connected; alternate roots are a blatant disconnection. Do not go there.

/Måns, DNS operator, from the country where we have DNSSEC.

Stephen Smoogen • April 9, 2007 11:54 AM

Here is the silly thing.. the signing of zones via DNS-SEC is very cpu intensive. A story I heard was that it took Verisign 16 weeks of time to sign a snapshot of the entire .com address space using a large cluster of computers. That basically meant that it was not a service that could be useful for modern DNS.

I think that if DHS took over the keys.. it would definately be the camel that broke the back of ICANN, and the Internet would route around it.

Mike • April 9, 2007 12:00 PM

anti-American paranoia is always news!

Just remember kids, whatever the US does is always bad,bad,bad. If you accept that, rationalizing the world is much easier.

nedu • April 9, 2007 12:01 PM

Suppose —instead of DHS— that DoC, via NIST, contracted with NSA to sign the root on behalf of the United States. Would that make people feel more comfortable?

At least NSA has a track record…

Who do the Europeans trust?

Roy • April 9, 2007 12:02 PM

The US government must have the ability to spoof the system, so that it can fool itself about where packets originate. This will be absolutely necessary for false-flag operations. Thus the government wants a system that is both as tight as a drum and as loose as a goose.

HmD • April 9, 2007 12:18 PM

“anti-American paranoia is always news”

I think that is not the point of the post at all. The point is that of the ~1000 million users of the Internet, only ~200 million are in the USA (Ref. CIA factbook, [1].) There are more internet users in the EU than in the USA.

Even if having control of the DNSSEC root tree were fundamental for the mission of the DHS, it only has jurisdiction over 20% of the Internet users. What about the other 80%?

[1] https://www.cia.gov/cia/publications/factbook/rankorder/2153rank.html

Måns • April 9, 2007 12:23 PM

The signing process is not so hard.

SE is signed. At 600000 delegations, it is
1/55 of .COM, approx. There is a new zone from SE every two hours. Resigned from scratch, and it could be pressed to once every hour without problems.

Also, there is this little thing called “incremental signing”, where one needs to sign only the delta between revisions. The churn for SE is around 0.03% per 2h, last time I checked, making the resigning trivial.

The “it will take ages to sign” horror is sooo 1999 — I signed the then 90000-delegation SE as a test on my Ultra5 back in 2000, with the proof-of-concept tools of that era. Took some 2 hrs.

Matt • April 9, 2007 12:24 PM

I’ll give another shout-out to the Matasano post that Jeremiah Blatz linked to. However, I think the takeaway message from Ptacek’s rant so far is that we shouldn’t care about DNSSEC, because it’s not going to be deployed in any meaningful way anytime soon.

greg: The glut of zombie machines on the market has made IP spoofing somewhat irrelevant. I’d be happy if IP spoofing went away, but there are absolutely more important problems in the network security arena.

Richard • April 9, 2007 12:44 PM

I dont trust The DHS at all. If you do a bit of research into 9/11 and other happenings, you will find that there is what you are told, and then there is the truth, and the two do not line up at all.

greg • April 9, 2007 12:57 PM

@Matt

Very good point. The weakest link is not the IP stack at all. Its us, the users. Why am I not suprised.

Spider • April 9, 2007 2:00 PM

I like the idea, but it needs to be internationalized.

Id like the keys themselves to be encrypted several times, so a set number of countries would encrypt the keys with their private key.

If anyone needs access to the DNS keys, they have to get the permission of the other members of the controlling board and present their case. After each use new keys are generated.

or Something like that.

nostromo • April 9, 2007 2:04 PM

Do you trust the DHS?

Ask anyone who’s on the no-fly list because their last name is (for example) Stevens.

Forwarder • April 9, 2007 3:41 PM

@Hagai

“DNSSEC is aimed at protecting against hackers, not against national espionage.”

Isn’t hacking a significant part of military and industrial expionage these days?

Dave Howe • April 9, 2007 3:50 PM

I wasn’t aware that
a) DNSSEC was actually being used by anyone or that
b) having a copy of the key would allow anything other than spoofing a dns record – which is no more valuable than spoofing the response from a target server directly, and more likely to be discovered by a user who cares to check the target IP (while a classic mitm interception wouldn’t be)

that said – wasn’t a key element of dnssec the proposed integration with ipsec (to authenticate endpoint keys via the dns)? maybe someone at the DHS read that and wanted to be able to fake IPSEC exchanges without alerting the end user?

Sam • April 9, 2007 3:56 PM

@Thomas H. Ptacek:

Thats one of my big frustrations with this blog… Bruce seems to have taken off his cryptographer hat, and put on a “general security expert” hat, that I’m not sure he’s qualified to wear.

The article postings have very little commentary from Bruce… I’d much rather see fewer “news” postings, and more detailed comments on cryptographic and technical security matters (ok, and squids).

Maybe its just me…

Thomas H. Ptacek • April 9, 2007 4:00 PM

One assumes our host has few comments on DNSSEC-the-protocol; who could blame him, it’s vanishingly unlikely that we’ll ever use it

But DNSSEC-the-idea — an Internetwide PKI wedded directly with the DNS — seems like something our host could engage directly.

As everyone who’s noted our blog has pointed out: I’m not a fan of the idea. I think it’s silly. The Internet doesn’t need a secure DNS; it already has end-to-end secure transports and DNSSEC doesn’t get rid of Denial of Service.

antibozo • April 9, 2007 4:18 PM

DNS is not solely about mapping hostnames to IP addresses. The lack of security in DNS has largely kept it from being more than that until now, but with DNSSEC a lot of possibilities exist, e.g. using DNS as PKI for distribution of x509 certificates, GPG keys, etc. This would free people from the Verisign/Entrust overlords, and allow development of more versatile TLS-like protocols that use out-of-band certificate distribution. This is the key to letting IPsec and SMTP/STARTTLS really catch on, and a solution to the one-ip-per-SSL webserver status quo.

Critics who say DNSSEC is useless because IP spoofing is still possible are thinking small. And handing over the root keys to DOD would effectively destroy DNSSEC’s ability to become a worldwide secure namespace for all sorts of things.

Thomas H. Ptacek • April 9, 2007 4:22 PM

You can build those services anchored by TLS and HTTP and not disrupt the DNS in the process, and IP spoofing is not the argument here, DNS spoofing is.

Why should we want a “worldwide secure namespace” tied to the DNS?

antibozo • April 9, 2007 4:34 PM

Why should we want a worldwide secure namespace (e.g. cn attribute in x509 certificates) that is NOT tied to the DNS (the namespace of cn in x509 certificates)? What do you think those certificates get validated against? Telephone numbers? If DNS records are the glue between the certificate and the TLS service (which they are), why are certificates being signed by a third party who has to validate the identity of the requester?

bzelbob • April 9, 2007 5:29 PM

Concerning DHS, I tend to agree with Robert Steele (that Open Source Intelligence guy) who said in one of his speeches that “…the Department of Homeland Security is a massive humongous f**ked up failure.”

Definitely not the people I trust to run anything connected to running the internet.

Anyone who wants to take over running this stuff must first show that they can do their own job correctly, before we give them anything more.

Thomas H. Ptacek • April 9, 2007 6:02 PM

Antibozo: Because that decouples the security, trust, and policy requirements of applications from the implementation details of the Internet, allowing different applications to obtain appropriate security guarantees without imposing a burdensome lowest-common-denominator of security on everything?

Did you read the posts I wrote? I won’t repeat them here, to everyone’s relief, but you can find my arguments at:

http://www.matasano.com/log/case-against-dnssec

antibozo • April 9, 2007 7:19 PM

Thomas H. Ptacek> Because that decouples the security, trust, and policy requirements of applications from the implementation details of the Internet, allowing different applications to obtain appropriate security guarantees without imposing a burdensome lowest-common-denominator of security on everything?

Let’s visit your earlier secure-everything-with-TLS-and-HTTP proposal. Currently there are two types of certificates: low-cost, barely authenticated certificates which prove nothing, yet are still costly enough to rule out purchasing one for every DNS name, and “extended validation” certificates, which are exorbitantly priced and can only be issued to organizations that satisfy many requirements, chief among them being wealth.

This PKI is a bad joke, albeit an expensive one, since even the cheapest useless certificates still cost US$30 or so per name. Thinking you can truly secure applications using this PKI is naive, as is assuming that the cost of deploying DNSSEC will exceed the cost already being expended on annual certificate renewals for hundreds of thousands of organizations.

Possibly the majority of DNS maintenance is handled by the big registration and hosting providers via their web front ends. DNSSEC for these will be a matter of tweaking their back ends to do signing operations. For the rest of us, yes, we’ll have to learn a few new tricks. But your feared “lowest-common-denominator [sic–obviously you mean greatest common denominator] of security on everything”, to the extent that it is an accurate characterisation, is not going to be the least bit burdensome for most end users, and the advent of universal PKI will vastly reduce complexity in many other ways, forseen and unforseen.

As for keeping things decoupled, nothing forces you to publish a public key for every A record or CNAME in your zone. The security and policy requirements of applications are unaffected by having secure DNS information. But applications with security requirements can take advantage of a DNSSEC-based PKI if they want to.

PKI and end-to-end security have been a chicken-and-egg problem for a long time. The CA industry arose as the dominant chicken, but it’s a phony, McNuggets-style chicken. DNSSEC may not be the perfect chicken in every way, but it will produce eggs. If you have a tastier chicken in mind, please enlighten us.

And yes, I did read your postings, and they’re slanted so steeply I almost slid out of my chair.

Curt Sampson • April 9, 2007 8:43 PM

If you’re using DNSSEC, you must sign every record under the top level of your zone, or not sign any. This is so that you can verify the non-existence of records.

I’d like to second the opinion that adding security to DNS lets us use it for additional applications. For example, the current ssh infrastructure has you distribute host key fingerprints by copying them over to every machine every time a fingerprint changes. This, to put it bluntly, sucks, and sucks enough that most ssh users never verify host key fingerprints. And it makes changing hosts a serious pain: when I move, say, my subversion repository to another server, I have to update every machine from which developers access it.

I’ve started using DNSSEC to distribute SSHFP records to solve this problem, and it works pretty well, once you can actually get DNSSEC working, get the appropriate version of OpenSSH with the appropriate patches on all your machines, etc. Unfortunately, DNSSEC is difficult to set up (speaking as someone who has built an entire ISP infrastructure) and even harder to debug (in large part due to lack of decent logging in BIND 9). At this point, I can’t see anybody but the most experienced sysadmin setting up anything other than the odd signed zone here and there.

KH3m1st • April 9, 2007 9:06 PM

The internet is an international community and should be overseen and governed by an international body not the DHS. The Bush administration does not have the best record concerning trust in my opinion. They spy on their own citizens (supposedly for security reasons – hello USSR). The USA should NOT be the overseers of the DNS servers. This needs to be an international effort with the USA as a member of the governing body with an equal vote.

Thomas H. Ptacek • April 9, 2007 9:12 PM

Any end-station that wants to use DNSSEC to perform some new high-level key distribution function (such as DKIM) will need to install new software anyways.

So, if you have the choice of overhauling the entire DNS protocol, replacing it with a new “secured” version of dubious design, or simply installing new trust anchors for your existing TLS services (to avoid the $30 cert fee), you choose to overhaul the DNS? Why?

The funny part is, you’re escaping the clutches of Verisign, greedy Certificate Authority, by leaping into the arms of Verisign, root nameserver operator and registrar. Nice!

antibozo • April 9, 2007 9:45 PM

Thomas H. Ptacek> Any end-station that wants to use DNSSEC to perform some new high-level key distribution function (such as DKIM) will need to install new software anyways.

Your point being? (I install new software all the time. So what?)

Thomas H. Ptacek> So, if you have the choice of overhauling the entire DNS protocol, replacing it with a new “secured” version of dubious design, or simply installing new trust anchors for your existing TLS services (to avoid the $30 cert fee), you choose to overhaul the DNS? Why?

Kindly explain how isolated trust anchors facilitate IPsec–or any protocol requiring key exchange, for that matter–between differing organizations?

Yes, given a choice between something that doesn’t work, and something that can work, I choose the model that can work. Wouldn’t you? SSL v2 was flawed; it got replaced, didn’t it?

Thomas H. Ptacek> The funny part is, you’re escaping the clutches of Verisign, greedy Certificate Authority, by leaping into the arms of Verisign, root nameserver operator and registrar. Nice!

Registrars (I don’t use Verisign) will only be able to jack up domain registration fees slightly to add zone signing. Compare $950 per name for an Entrust “extended validation” certificate with a small signing fee for a zone root and unlimited signing operations after that. Effectively, every zone will have its own CA certificate, at a fraction of the cost of a current real single-host certificate.

Here’s a suggestion: take that biased tone you’re so expert at and dissect TLS v1 with the same vim you’ve applied to DNSSEC. I’m confident you can make TLS look overly complex and ineffectual if you work even half as hard as you have with DNSSEC. Don’t skimp on the nice diagrams too. And for extra measure, go buy a $30 “trusted” certificate from any of the cheap CAs and incorporate an analysis of its cleartext email-based authentication mechanism into your report.

Thomas H. Ptacek • April 9, 2007 10:08 PM

For whatever it’s worth, antibozo is right. I am biased. I think TLS is much better protocol than DNSSEC, DNSSECbis, or whatever DNSSECter will turn out to be. TLS is a really nice protocol.

I have no money riding on that judgement, though.

JeffH • April 10, 2007 2:58 AM

Seems to be a classic case of the US agencies thinking they have claim to what is now an international system. No small wonder that other countries talk about having separate internets with their own internationalised domain naming, when we see what the US typically manages in terms of foreign policy, or security policy.

When the US recognises that it should not (different from cannot) be trying to tell the rest of the world what to do, it will find people in other countries a lot more receptive to requests for ensuring security, which would be a good thing.

The issue isn’t that one organisation will probably have the keys (though I rather like the proposal of several required keys between several separate international organisations, not just one with one US agency), it’s the arrogance that the DHS has in assuming that it has the right, esp. when the usage of the Internet is no longer mostly in the US.

Greg • April 10, 2007 3:36 AM

@Sam

While I aggree that there is less real crypto here than there use to be. I don’t think Bruce is unqulified as a general security person. Why, because general security is a PRATICAL problem. And pratical experenice counts for more than some stupid cert from some “security” school.

Never underestimate Experince.

But then Bruce is a smart guy and I think many of his readers are too. He knows that they won’t blindly take everything here as the only “truth”.

However it would be cool if we could have a crypto day? like the squid day.

Nick • April 10, 2007 3:46 AM

To the posters who accuse others of “anti-US paranoia” in not wanting a single country to control the infrastructure of the global Internet:

Why not let the EU control the root signing key?

…and, as you all rush to explain why it would be unwise to allow the EU to control U.S. critical infrastructure, please then consider that the same argument might also be valid with the names reversed?

Skizmo • April 10, 2007 5:11 AM

“Since we are the leaders of the free world, why wouldn’t the world want us protecting and caring for the Internet?”

STOP dreaming .. america is NOT the leader of the free world. Leaders don’t destroy what they lead !

nedu • April 10, 2007 8:48 AM

@Nick,

If the European Union were to nominate an agency with technical capabilities and experience comparable to the U.S.’s NSA, then we might discuss that agency’s role in signing the root.

I’d expect that the UK might desire to participate with the EU. But, the UK also has historical, cultural and economic ties with nations outside of Europe, and those should not be neglected. India, for instance, is the most populous nation within the Commonwealth of Nations. I wonder if it might be worth pursuing discussions aimed at finding some formally-agreed technical cooperation that would be acceptable to other members of The Commonwealth.

rob • April 10, 2007 9:47 AM

Bruce … any chance you could provide some more insight into this? What are the implications here? It sounds bad on the surface, but a lot of us are not technically savvy enough to immediately understand why.

The commenters get into it, but they frequently contradict each other and I don’t know who these people are. You I trust as a level-headed, thoughtful and intelligent guy who knows what he’s talking about.

There are many posts like this where I’m left with more questions than answers.

sooth_sayer • April 10, 2007 10:39 AM

Another one of these “Big Deals” by Bruce.
If there are keys someone has them, are we more secure because some unknown dufus (or dufii) in some unknown organization with totally unknown intentions, plans and without ANY controls has them.

This is another major non-sense Bruce indulges in .. may be sometimes the government is “bad”, but it’s “ours” (still .. I think). So fix that end of it .. not promote this hysteria.

And who says Europeans are any better .. by all accounts they are pretty bad .. anyone cares to remember hitler, vichy, uncle joe the man of steel.. illescue (i hope i spell Him right).. tito .. the list goes on and on .. and their neighbors .. Mao .. Polpot et.al ..

Thomas H. Ptacek • April 10, 2007 12:17 PM

The most important thing you should know, if you’re not familiar with DNSSEC, is that there is no current operational deployment of the technology on the Internet, just private experiments.

Thomas H. Ptacek • April 10, 2007 1:37 PM

They don’t mean anything without deployment of DNSSEC-capable resolver caches to validate their signatures. Also, any stats on how many zones they’ve signed?

antibozo • April 10, 2007 1:40 PM

Thomas H. Ptacek> They don’t mean anything…

So your argument is that DNSSEC is a failure because it hasn’t been fully deployed, and since it’s a failure, we shouldn’t deploy it. Nice.

Jess • April 10, 2007 5:02 PM

antibozo> Kindly explain how isolated trust anchors facilitate IPsec–or any protocol requiring key exchange, for that matter–between differing organizations?

I haven’t spent as much time on this as you and Thomas have, but from a trust perspective, this is hazy. Why do we trust Verisign? What stops us from trusting CAcert? Why should we abdicate these decisions to Commerce or our default browser config? For every relationship among parties that requires trust, those parties should choose how they verify that trust.

It would be nice if there were some central authority on which we could rely for absolute infallible trusted interaction, but that isn’t the case. Those who want to make interaction easy put up with a certain level of failure as a cost of doing business. Those who want a really tight system won’t be satisfied by anything that DNSSEC is offering and will have their own end-to-end thing anyway. What’s the sweet spot we’re trying to hit?

DHS has been a centralizing bureaucratic boondoggle from the start, so I’m not surprised they’re involved. But I’m not trying to tar DNSSEC with the same brush; I’m genuinely curious as to what it gets for us? From my perspective, it just seems like more telco-style “smart network” folly, but I’d love to learn otherwise.

Anonymous • April 10, 2007 5:28 PM

@Spider: “Id like the keys themselves to be encrypted several times, so a set number of countries would encrypt the keys with their private key.”

Then the governing board will be just as agile and effective as the UN Security Council. Might as well have the UN Security Council actually do the signings, for that matter – at least the useless bureaucracy is already in place, and won’t have to be rebuilt (and funded) from scratch.

antibozo • April 10, 2007 8:46 PM

Jess> Why do we trust Verisign?

Some of us don’t. ;^)

Jess> For every relationship among parties that requires trust, those parties should choose how they verify that trust.

Some musings on the issues you raise…

The problem of trust here is really two separate problems:

A. How do we know that the system we reach at bankofamerica.com is managed by the owner of the bankofamerica.com domain?

B. How do we know that the owner of the bankofamerica.com domain is Bank of America?

Current standard certificates undertake to address only problem A; problem B is now left to “extended validation” certificates. In addition, in a lot of cases (perhaps most), problem B doesn’t exist because the domain name is all the identity we care about. If I send mail to example.user@gmail.com, I don’t really care who owns gmail.com; all I care about is that the email reach gmail.com and not a MITM.

A DNSSEC PKI also addresses only problem A. It does so more directly, however, since domain ownership and the ability to sign DNS records are tightly bound. With x509, CAs have to find a way to authenticate domain ownership independently. In most cases this relies on contact information in the domain registration, and there are dozens of ways to subvert the authentication process.

So what are some risks in a DNSSEC PKI? Assuming the public signing key for a domain is established as part of the registration process and managed via interaction with the registrar, then validity of signed zone data can be undermined by the following:

  1. Compromise of the domain’s signing key.
  2. Compromise of an ancestor zone’s signing key.
  3. Compromise of the domain owner’s registrar account.
  4. Compromise of whatever mechanism registrars use to submit public keys to the TLD registries for signing.
  5. Other things I’m probably overlooking.

For 1, the domain’s signing key is easier to protect than the private key for an existing x509 cert, since the signing key can be kept off line. The impact of compromising the signing key is higher, though, since it effectlvely allows the attacker to issue unlimited certs.

The impact of 2 is similar to the impact of compromise of any of the x509 signing keys of any of the current accepted CAs. I.e., if I compromise any private key for any of the dozens of CA certs in the typical trust database, I can issue x509 certificates that look just as valid as any other standard cert. The DNSSEC model is arguably of lower risk then, since there are far fewer keys to protect (for example.com, just the .com and . signing keys).

For 3, since most current validation for issuance of standard x509 certs is based solely on domain registration data, compromise of the registrar account has similar impact in either PKI model. (Although, perversely, the fact that CAs charge for certificates may limit the impact in the x509 model.)

4 is something I just don’t know about. Maybe someone else can fill in how registrars will communicate signing keys to the TLD registries securely.

As an aside, one of the risks people who use isolated trust anchors often overlook is typified by the following scenario:

MegaCorp has its own x509 PKI and a self-signed CA cert as its trust anchor. For telework VPN and intranet access, it requires employees to import the CA cert into their offsite trust databases so that their browsers and VPN clients can successfully validate certs from MegaCorp’s PKI. Now one of the MegaCorp PKI admins wants to commit a little larceny. He uses the MegaCorp PKI private key to issue a certificate for bankofamerica.com, and can now perform a MITM attack against any employee, since MegaCorp’s CA cert in the user’s trust database looks just as valid as Verisign’s to the user and his browser.

This scenario doesn’t apply in a PKI model where signing authority follows a hierarchy, such as a DNSSEC-based PKI, since the signing key for megacorp.com can’t be used on bankofamerica.com.

People who know better should feel free to correct me on any of this.

toooldforthis • April 19, 2007 4:01 PM

What control does holding the private part of the KSK for the root give DHS/US? Why do they want it?
Maybe I am missing something but cant an ORSN or any other alternate root system simply publish its own public KSK part (trust anchor) for inclusion in resolvers/DLV and offer the same service (by effectively signing the publicly visible DS records for all TLDs just like ICANN/VRSN would do) ?

It then just comes down to making sure the MSFT resolver has the option of adding additional trust anchors – which it likely will as part of some general cert management.

PackagedBlue • November 25, 2008 11:07 PM

DNSSEC in the news, and see slashdot on this date.

Also IETF comments have ended 11-24-2008. Pdfs, at link.

http://ntia.doc.gov/dns/dnssec.html

With all that has happened in the last 8 years, rushing DNSSEC reminds me of the 08 Finance crisis rebuild of bank bailouts, rushed and no accountability.

Leave a comment

Login

Allowed HTML <a href="URL"> • <em> <cite> <i> • <strong> <b> • <sub> <sup> • <ul> <ol> <li> • <blockquote> <pre> Markdown Extra syntax via https://michelf.ca/projects/php-markdown/extra/

Sidebar photo of Bruce Schneier by Joe MacInnis.