ICANN and NIST Announce Plans To Sign the DNS Root

jhutkd writes "On June 3rd, 2009, ICANN and NIST announced formal plans to use DNSSEC to sign the DNS root zone by the end of 2009. This is a huge step forward for the deployment of DNSSEC."

Comments

VeriSign

[drDugan]

Wasn't VeriSign the one who set up the brain-dead system where now we all get to pay them (or a few connected competitors) for the privilege to share secure content with https?

I hope we do that again for DNS servers!

</snark>

But seriously, what's the busines model for maintaining the certs?

Re:VeriSign

[Anonymous Coward]

What's the business model?

http://epic.org/privacy/dnssec/
outlook is not good:

The pilot in Sweden has shown that top-level registrars are not willing to pay 50 euros a year for DNSSEC. The implementation of DNSSEC has proven to be pricely and it is difficult to develop an viable business model and pricing strategy. Sweden proposed a skimming strategy: setting the price high and lowering it to increase demand.

http://www.techworld.com/security/news/index.cfm?newsid=116607

A lack of customer demand for DNSSEC and the cost of deployment are two of the main reasons for operators either hesitating or choosing not to implement the technology in the near future, according to ENISA.

Re:VeriSign

[Anonymous Coward]

There are no certs, just signed DNS records. All DNS records which are published in a DNSSEC enabled zone (the root "." zone in this case) are signed with the public key of that zone. The public key of a delegated zone is just another record. There is nothing special about it which could justify an extra charge.

The additional cost of installing and maintaining the DNSSEC system is incurred for the zone as a whole. There is no individual authentication overhead beyond what is already necessary to make sure that only the domain owner can change the delegation records of a domain.

Re:VeriSign

[Anonymous Coward]

Wasn't VeriSign the one who set up the brain-dead system where now we all get to pay them (or a few connected competitors) for the privilege to share secure content with https?

You can set up your own secure content with https. But why should the general public trust your certificate? You pay verisign (or another trusted CA) to vouch for your secure content.

Without someone vouching for your certificate, there is no proof it's yours, and it's spoofable.

My company has its own CA. It's pushed out to all company computers automatically by domain policy. Works great for internal company sites, but for public sites, we use signed certificates from a real CA.

I hope we do that again for DNS servers!

You got a better idea? Maybe governments or domain registrars would sign certs?

Re:VeriSign

[Anonymous Coward]

what moron modded "You pay verisign (or another trusted CA) to vouch for your secure content." as informative?

they vouch for the fact someone had a credit card once and they got paid.

Re:VeriSign

[Timothy Brownawell]

they vouch for the fact someone had a credit card once and they got paid.

The processes that CAs go through before signing a certificate certainly should be a lot stronger, but the idea of a trusted certificate authority is still valid.

And some CAs are diligent...

The basic idea is valid, but the implementation sucks (and can probably only be made to not suck in a closed environment). Some CAs being diligent isn't enough, they all (well, all the ones trusted by any major browser) have to be diligent for the system to work at all. My choosing the best CA out there doesn't matter a bit, because they can't do anything to stop the worst from handing a phisher a cert for my domain.

Re:VeriSign

[cicuz]

Just to clarify: they are not signed with the Zone Public Key, as that would somehow defeat the purpose of this whole initiative ;)
Records are signed with the Zone Private Key (kept in a safe, probably underground) on a disconnected machine, then made available to the wild (as I remember DNSSEC from Computer Networks, Tanenbaum).

Re:VeriSign

[TheRaven64]

You're missing the point of SSL somewhat. To establish a secure connection between two computers, they need to exchange keys. With public-key encryption, you can both send your public key and no one can intercept the traffic. As long as you both encrypt with the other's public key, the traffic can only be read with the private key.

A self-signed certificate works in exactly this way. The problem is that a third party can sit in the middle and carry out the key exchange with both of you. You both get the intermediary's public key and encrypt with that. The intermediary decrypts the conversation, reencrypts with the other party's key, and either just records or modifies the plaintext in the middle.

This is possible because there is no way of ensuring that the self-signed certificate really comes from the other machine. Self-signed certs are better than no certs, because they protect you from passive attacks, but they still leave you vulnerable to active attacks. If you use a third-party CA trusted by the client then the certificate that they receive is signed by the CA's key. The certificate is not just a public key, it also contains information about the domain name and company name of the remote machine. If the CA's signature matches then the client can be sure that the remote machine is owned and operated by the people who bought the certificate. This doesn't prove that it is the machine that they think it is, but it generally shows that there is no intermediary intercepting the communication.

This becomes more interesting when you add DNSSEC. Each DNS zone is signed by the parent zone. This means that you can trust that everything you get from DNS is definitely set by whoever is meant to be in charge of the DNS zone. Because DNS can carry arbitrary text strings, not just resolving information, you can put a public key in there and use it to negotiate an SSL connection. This doesn't require any third-party, which is why companies like Verisign are so hostile to it - it effectively eliminates their business model.

Re:VeriSign

[cdhgee]

You forgot your opening tag :-P

Yeah, that'll help

[QuantumG]

The problem is that there are SSL cert providers who will happily hand over valid certs to anyone with a credit card, and browsers are configured to automatically trust these bozos. And the ones that are actually diligent in checking credentials will happily hand over username/password for web administration of the domain to anyone who knows the date of birth of the current registrant.

Re:Yeah, that'll help

[spinkham]

Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that "All the world's a Browser', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy network infrastructure may be long even though the days of thy current technology be short.

Apologies to Henry Spencer.

Re:Yeah, that'll help

[AnyoneEB]

If DNS is trusted -- that is, all data a client receives upon querying a domain's DNS record is trusted to be fully controlled by the owner of that domain -- then, theoretically, public keys could be stored there. That means that instead of getting an untrusted certificate from an HTTPS server which the user's browser has to examine for a signature from a trusted authority, the HTTPS server can simply say, "Hey, of course it's real: the fingerprint matches the one in my DNS record." without any external authority required (other than the one implementing DNSSEC, of course). That means once DNSSEC is implemented for the root and a site's top-level domain, the only part that needs to be trusted is the public keys of DNS root.

That said, I have yet to see an implementation -- or even protocol specification -- of such a protocol. Does one exist or is this purely theoretical at this point?

Re:Yeah, that'll help

[???]

Please name such a CA which "happily hand over valid certs to anyone with a credit card" and does not "take reasonable measures to verify that the entity submitting the certificate signing request has registered the domain(s) referenced in the certificate or has been authorized by the domain registrant to act on the registrant's behalf" and which is trusted by the major browsers.

And then, perhaps, explain why you feel this is in _any_ way relevant to a discussion on DNSSEC.

Though, I suppose, this is Slashdot. Why post based on relevant facts rather than baseless, off-topic innuendo?

Re:Yeah, that'll help

[spinkham]

It does in fact matter.

First DNSSEC is orthogonal to SSL, and many network protocols where SSL is not involved can benefit from DNSSEC. Whenever people break DNS to serve ads instead of NXDOMAIN responses, they've committed the above heresy. When SSL put forth as a reason for not needing DNSSEC, the same applies.
I'm not convinced one way or another if the original poster was thinking that way, but it is often the case.

Also the DNS attack surface is not comparable to SSL.
There is but one DNS entry that can be assigned to a user. I can't request slashdot.org from a vendor and get it. If someone owns a domain name, only that particular registrar has the power to change the domain name. So if I choose a reputable registrar, I'm covered.

By contrast, I can request an SSL cert from any provider on the planet. If I already own a SSL cert, a company doesn't have to check a master registry before they issue another cert.

In effect, with DNS, the defender choose the battleground by choosing the most secure registrar. With SSL, the attacker chooses the battleground by choosing the least secure certificate authority.

Re:There is a curious lack of small DNSSEC resolve

[spinkham]

Windows 7 and Windows Server 2008 R2 have one built in, and Unbound is a smaller DNSSEC aware resolver for Unix like OSs.

ICANN?

[InsertWittyNameHere]

ICANN haz DNSSEC?

Us!

[SEWilco]

All your root are belong to us.

DNSCurve

[Helios1182]

I still think DNSCurve would have made more sense, http://dnscurve.org/dnssec.html

Re:DNSCurve

[Timothy Brownawell]

I still think DNSCurve would have made more sense, http://dnscurve.org/dnssec.html

DNSSEC certifies the data, while DNSCurve only certifies the connection between the DNS server and the resolver.

With DNSSEC, you know that the DNS records you receive are correct.

With DNSCurve, your ISP's caching resolver knows that it is talking to the proper DNS server. You do not know that you are talking to your ISP's resolver instead of an imposter, and you do not know if your ISP is forwarding the records accurately.

DNSSEC can be used for interesting things like distributing public keys. DNSCurve cannot, because it still requires you to trust your ISP and your ISP's network. (Or alternatively it would require that shared caching resolvers not be used, which would cause a major increase in traffic to the authoritative servers.)

the problem with securing DNS is the DNS is secure

[wayne]

The big problem with DNSSEC, if widely used, is that it prevents forgery of DNS responses. ISPs and internet cafes will not like this, since that means they can no longer forget DNS replies to missing domains or to force people through registration pages. I can see a *LOT* of push-back from having end-users using DNSSEC.

Who holds the master key?

[karl.auerbach]

Who will be the person who gets to hold the master crypto keys used to sign the root zone?

Somebody, somewhere, has to do this. Who?

Re:Who holds the master key?

[papafox_too]

Homeland Security demanded (and subsequently received) a copy of the root DNSSEC master keys from ICANN. They presumably want them so that they can perform man-in-the-middle attacks against any .com/.net/.org domain.

So what?

[damn_registrars]

They can take all the measures they want to secure the root, if they keep letting unscrupulous registrars sell domains it all will be for naught anyways. Wake me up if they ever decide that for some reason they feel security and stability are suddenly more important than profit.

Re:the problem with securing DNS is the DNS is sec

[Anonymous Coward]

If you are in the path of the traffic, you can simply redirect the HTTP connection instead of forging DNS replies. DNSSEC will not even put an end to NXDOMAIN hijacking, because that is done by the recursive resolver and if that isn't under the user's control then the user is not validating DNS. Most users will keep using upstream DNS servers, which means that DNSSEC can prevent third party manipulations of that server's responses, but not manipulations which are injected on the "last hop".

Re:the problem with securing DNS is the DNS is sec

[Timothy Brownawell]

Most users will keep using upstream DNS servers, which means that DNSSEC can prevent third party manipulations of that server's responses, but not manipulations which are injected on the "last hop".

Huh? Sure it can:

http://www.rfc-archive.org/getrfc.php?rfc=4033 (page 11, just before section 8)

There is one more step that a security-aware stub resolver can take if, for whatever reason, it is not able to establish a useful trust relationship with the recursive name servers that it uses: it can perform its own signature validation by setting the Checking Disabled (CD) bit in its query messages. A validating stub resolver is thus able to treat the DNSSEC signatures as trust relationships between the zone administrators and the stub resolver itself.

(a "stub resolver" being the system library that implements getaddrinfo() and friends)