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]

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

[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.

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

[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: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?

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.