DNSSEC Implementation Held Up By Tech Delays

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

Comments

Can someone explain ZSK and KSK?

[rsborg]

Kane said that VeriSign will create and manage the zone-signing key (ZSK) for the root zone, and sign the root zone, for .net and .com. Icann will create, manage and publish the root zone key-signing key (KSK).

This is over my head, as the terminology seems repetitive (ZSK for root zone vs. root zone for KSK ?!?!)... can anyone explain the details to a DNSSEC initiate (A quick google search didn't yield any easily understandable content).

Re:Can someone explain ZSK and KSK?

[vlm]

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

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.

Technical delays, Yeah Right.

[lbalbalba]

Unable or unwilling admins is more like it.

Re:Technical delays, Yeah Right.

[Anonymous Coward]

Yeah, Verisign, the largest certificate authority, is the organization responsible for implementing the feature of DNS that basically makes certificate authorities less necessary? I'm sure they're all over trying to get this done quickly.

Re:uh

[lbalbalba]

Well, actually, I kinda sorta like it when the article summary's actually summarize the core concepts that there talking about.

Why use digital signatures?

[Myria]

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 feel that it's necessary to use digital signatures to secure the system.

The fundamental flaw of DNS is that the "nonce" - the one-time-use random constant used to prevent spoofing - is only 16 bits. If you're going to change the DNS protocol, why not just increase the size of that field to 64 bits and be done with it? Then it's only a software change to DNS servers rather than an expensive certificate and far less of an administrative headache.

Also, I don't think that it's even necessary to change the protocol. The protocol allows for multiple DNS queries in one packet. When doing a DNS query, ask for both www.google.com and a nonce domain like eujrdyhtaeoym.example.com. If the query comes back saying that eujrdyhtaeoym.example.com does not exist (or even if it says it does!), you know nobody is spoofing DNS queries back at you because unless they were snooping traffic, they wouldn't have a way to know that your nonce was eujrdyhtaeoym.

Re:Why use digital signatures?

[Burdell]

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/, you really got www.foo.com's certificate and not that of a man-in-the-middle attacker).

Re:Why use digital signatures?

[JesseMcDonald]

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.