Slashdot Mirror
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."
← Back to Stories (view on slashdot.org)
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.
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?
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.
How we know is more important than what we know.
Windows 7 and Windows Server 2008 R2 have one built in, and Unbound is a smaller DNSSEC aware resolver for Unix like OSs.
Blessed are the pessimists, for they have made backups.
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.
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.
I am TheRaven on Soylent News