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

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?

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

[???]

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.

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

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)

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.