DNSSEC Implementation Held Up By Tech Delays 57
Posted
by
timothy
from the not-just-those-dogs-in-the-hallway dept.
from the not-just-those-dogs-in-the-hallway dept.
Jack Spine writes "VeriSign has said that the main obstacle to DNSSEC implementation has been technical delays. The large size of the .com and .net domains would have made it impractical to deploy earlier versions of DNSSEC, according to VeriSign vice president of naming services Pat Kane. Deployment of DNSSEC will close a major security flaw in the DNS, the internet's equivalent to a telephone directory. The problem of DNS cache poisoning was thrown into sharp relief by researcher Dan Kaminsky last year."
Re:Can someone explain ZSK and KSK? (Score:3, Informative)
While you're explaining, can you tell us why DNSSEC makes the size of the DNS zones "unwieldy"?
Probably the agony of setting up precisely one zillion NSEC records makes the whole thing "unwieldy".
To properly return a cryptographically secure answer that there is no domain named silentdot.org, you need a line like:
shitdot.org NSEC slashdot.org
which is a pointer saying there is nothing between shitdot.org and slashdot.org.
http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_7-2/dnssec.html [cisco.com]
Of course the only thing that is constant about DNSSEC, other than megatons of FUD, is constant change in how it works. Maybe NSEC is now as obsolete as MD and A6 records now are, I really don't know.
Re:Why use digital signatures? (Score:5, Informative)
You should understand DNSSEC before criticizing it. It doesn't work with SSL-style certificates that have to be signed by a recognized certificate authority. Also, it doesn't change the existing protocol, it extends it in a (mostly) backwards-compatible way. DNS servers just have to know how to request and handle the new additional records; old servers and clients keep working fine.
Your proposed solutions only fix one small piece of the DNS problem, that of spoofed network packets. DNSSEC authenticates the entire response chain, so that (for example) you can be sure that your ISP isn't modifying responses to point you somewhere else (such as their servers) rather than what you requested.
With DNSSEC, you could possibly eliminate the SSL certificate authorities and use signed DNS records to include the certificate information (so you can make sure that when you go to https://www.foo.com/ [foo.com], you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).
Re:Why use digital signatures? (Score:3, Informative)
This really seems like a ploy by VeriSign and friends to make ever more people and companies to purchase signed certificates at $100/year or whatever.
I don't see anything in the DNSSEC specs which would require any external chain-of-trust similar to the current CA system. You just need a secure way to update your resource records with your registrar, which includes your DS (designated signer) record, a public key of your choosing. There's no authentication involved beyond your credentials to update the domain. It's too early to be sure, but this should be included with the purchase of a domain. Once you have your DS record in place you can use it to designate signers for any subdomains.
You could even use it to sign a resource record containing your web server's public TLS key, which allows a real solution to the problem of encryption-only websites: a self-signed certificate which can be securely matched against the host domain, preventing the trivial MITM attacks which currently render such certificates useless. CA-signed certificates would still be useful for establishing real-world identity, of course.