Follow Slashdot blog updates by subscribing to our blog RSS feed

 


Forgot your password?
Close
typodupeerror
×
The Internet Security

DNSSEC Implementation Held Up By Tech Delays 57

Posted by timothy 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."
This discussion has been archived. No new comments can be posted.

DNSSEC Implementation Held Up By Tech Delays More

DNSSEC Implementation Held Up By Tech Delays

Comments Filter:

  • Can someone explain ZSK and KSK? (Score:4, Insightful)

    by rsborg ( 111459 ) on Monday November 16, 2009 @02:50PM (#30120326) Homepage

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

    • While you're explaining, can you tell us why DNSSEC makes the size of the DNS zones "unwieldy"?
      TFA does nothing to explain the nature of their problem.
      Fairly useless as far as articles go.

      • Re: (Score:3, Informative)

        by vlm ( 69642 )

        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

        • Re: (Score:2)

          by hardaker ( 32597 )
          It frequently has to do not with just NSEC records but with memory requirements in general. Unfortunately, adding in all the crytographic hashes and NSEC records and keys tends to triple the memory requirements of a name server. Since versign and other folks would rather not publish a completely signed .com zone because of the added costs they're using NSEC3 instead which lets them skip publishing signatures for anything they don't want to. Thus there is very little cost change to them and they can still

      • Re: (Score:1, Offtopic)

        by nine-times ( 778537 )
        I'm going to put IANAE in all of my posts here, since I don't really know what I'm talking about in any depth. However, my guess would be that DNS records, being small by themselves, are dramatically increased in size by adding encryption keys and signatures.
        • I'm going to put IANAE in all of my posts here, since I don't really know what I'm talking about in any depth. However, my guess would be that DNS records, being small by themselves, are dramatically increased in size by adding encryption keys and signatures.

          Yah, a lot of DNS replies are really really tiny. As in under 64-128 bytes including packet header tiny. Just adding a 128/160/256 bit signature on top of the reply is going to bulk that up a fair amount. Plus you'll need the signing keys on top o

      • While you're explaining, can you tell us why DNSSEC makes the size of the DNS zones "unwieldy"?

        DJB held an interesting keynote at USENIX WOOT this year, on some of the unintended side-effects of DNSSEC. Here are the slides: http://cr.yp.to/talks/2009.08.10/slides.pdf [cr.yp.to].

        The biggest issue he found was that the a single, small DNS request triggers a huge DNSSEC response with lots of digital signatures (each one of which is at least 1024 bits...). Since the requests are sent over UDP, they can be spoofed. End result? a HUGE DOS amplification effect.

    • DNSSEC [wikipedia.org]

    • IANAE, but it sounds like the KSK is used to sign all the other keys to assure their validity. So you have a KSK for all of DNS, and you use that to sign ZSKs for each TLD...?

      I don't really know, but it seemed like it might be more helpful to guess and let someone correct me than to just post a link to a long technical explanation.

    • The KSK signs only DNSKEY records, and the ZSK signs all other relevant resource records in the zone. Your DNSSEC delegation comes from a DS record (a fingerprint of your KSK) which is included (and signed) in the delegating zone. The practical upshot of this is you can change your ZSK frequently without having to update the DS record upstream (thus contacting your delegator) every time you do so.

    • The KSK is the master key with which the various vendors ZSK keys are signed with. The ZSK key is then signing your key for domain.com This is so that the DNS-client does not have to have a long list of the various vendors keys as is the case with web browsers, all it needs to have is the KSK and with it it can verify the complete chain of certificates.
      • Wikipedia has some good info on this: DNSSEC involves many different keys, stored both in DNSKEY records, and from other sources to form trust anchors.

        * In order to allow for replacement keys, a key rollover scheme is required. Typically, this involves first rolling out new keys in new DNSKEY records, in addition to the existing old keys. Then, when it is safe to assume that the time to live values have caused the caching of old keys to have passed, these new keys can be used. Finally, when it is sa

    • Re: (Score:2)

      by hardaker ( 32597 )
      Because DNS tries to keep replies as small as possible for most of the data they introduced two types of keys into DNSSEC. One is a Zone Signing Key (ZSK) which signs all the data in a zone. The other is a Key Signing Key (KSK) which is used to sign just they keys in the zone (both ZSKs and KSKs are signed by it and the ZSK signs they keys too for that matter). This provides a number of benefits. Some people believe that ZSKs can be smaller and you can change them more frequently (on the order of every
    • It means that VeriSign will be signing the zone, while Icann will be acting as a CA and certifying the keys used by VeriSign.
    • This is typical Marketeer speak and crap. The existing DNS is data driven, via the Zone files for each (group) of Domains, the basic problem is that contrary to the small, simple friendly days of the arpa net, the distributed nature of the existing network of DNS servers is easily subverted by servers who deliberately lie in answer to DNS queries.

      The solution is well understood, use cryptographic signing, with a known Public Key, so that clients can verify that the answer they get is Genuine Signed. This wo

    • Re: (Score:2)

      by rs79 ( 71822 )

      Keep in mind they may be lying. We're supposed to believe with 10 years to work on this they're surprised that tha files are big? Uh, hello, no.

      I suspect what's really going on is they just found the intellectual property gotcha inherant in DNSSEC that IMO is gonna prevent it from ever being widespread. It's as damning to the IP/TM guys as the Kaminsky was to technical correctness of the DNS and I suspect the project's been put on hold... and may not come back in its present form.

      And then there's the .se de

  • Technical delays, Yeah Right. (Score:3, Insightful)

    by lbalbalba ( 526209 ) on Monday November 16, 2009 @02:56PM (#30120430)
    Unable or unwilling admins is more like it.

    • Re: (Score:3, Insightful)

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

      • I trust DNS more than CAs ... just use the DNSSEC keys for SSL and be done with it.

        • They are meant to solve different problems. DNSSEC lets you tell that 216.34.181.45 definitely is the right IP address for slashdot.org (and, if you put a public key in a TXT record or similar, lets you establish a secure connection with this IP). A signed certificate lets you know that you are communicating with a domain owned by Sourceforge Inc. For most uses, the former is more important, but for things like Internet banking you also want the latter.

    • Unable or unwilling admins is more like it.

      A side effect of buying into the so-simple a monkey could run it sales pitch from Microsoft: You end up with monkeys that can only stroke the big boss telling him or her to sit tight till the next free t-shirt^H^H^H^H^H^H^H service pack. As these monkeys are able to bullshit their way into training positions, they will do what any other weak or insecure monkey will do: bogart their already limited knowledge. Thus with each iteration you get progressively more ignorant monkeys, that have to rely and speci

    • I would say that the insane costs of a DNSSEC certificate is more probable as the reason...

    • There was also a political argument about who should be the root signatory.

      Since I would expect that the root signatory is able to forge DNS records for any part of the internet (or some such thing), it might be perhaps cynical of me to suggest that this wasn't entirely the simple prestige thing that everyone claimed it to be. ;-)

  • Why use digital signatures? (Score:5, Interesting)

    by Myria ( 562655 ) on Monday November 16, 2009 @03:15PM (#30120708)

    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.

    • Wish I had mod points. An interesting solution.

    • Re:Why use digital signatures? (Score:5, Informative)

      by Burdell ( 228580 ) on Monday November 16, 2009 @03:35PM (#30120998)

      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: (Score:2)

        by dkf ( 304284 )

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

        That would only really work for the most basic type of signing, where the CA is asserting that the certificate is for SSL use on www.foo.com. I suppose the extended validation attributes (like the company's formal business identity) could also be done that way, but I doubt that ISPs are likely to want to get into that game (the liabilities from errors are a good reason to leave that with specialists).

        For client certificates, a CA is really best. After all, I'm not a DNS entry, I'm a free man!

    • Re: (Score:3, Informative)

      by JesseMcDonald ( 536341 )

      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 desi

      • Re: (Score:2)

        by tepples ( 727027 )

        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.

        Watch registrars start charging for the privilege of serving DS records.

        • They have to serve some sort of DS record for DNSSEC to work at all beyond second-level domains. They could withhold DNSSEC support entirely, of course, but the concept of using one's own DNS servers for third-level and lower domains, or at least having them hosted by someone other than the registrar, is fairly well entrenched. I just don't see them successfully reversing that pattern or forcing such domains to remain unsecured.

          • Re: (Score:2)

            by tepples ( 727027 )

            They could withhold DNSSEC support entirely, of course

            Segmenting the market by withholding DNSSEC from customers on the $10 per year tier of domain registration is exactly what I meant, especially where VeriSign is involved.

      • As computers/algorithms get faster quick hacks fail ever sooner.

        Ther is little wrong with the design of DNSSEC except it allows --- FOR MONEY --- trust vendors a completely unrequired role in the system, DNSSEC could have easliy avoided this but this is a political question, you should provide your public key, self signed or not, and that needs basically to be the end of it. I can now advertise the fingerprint of my public key on my business card or signature.
    • I thought the idea was that all responses to DNS queries would be signed and therefore verifiable, and not that people would need to buy individual certificates from CAs.
      • That is the idea, but once you have that, it's fairly easy to replace x.509 certificates with DNS.
      • That is the idea. However, once you have DNS records that you can guarantee are authoritative, it's possible to store a key along with the address-to-name mapping. RFC 4025, for example, provides a way of putting IPSEC keys into DNS. These can then be used to establish an end-to-end encrypted connection at the IP layer so every packet sent to the IP looked up by the DNS query is encrypted. This eliminates most of the need for SSL on any protocol, because the connection is secured at a lower level.

        CAs

    • Re: (Score:2)

      by amorsen ( 7485 )

      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.

      DNSSEC, as originally conceived, did the exact opposite. Signing a zone was either-or, so the registrars couldn't charge each client for signing their records. Once you signed it for one client, you signed for them all. At the same time DNSSEC obsoletes SSL certificate authorities.

      Now, if you happen to be Verisign and make a lot of money selling SSL certificates, how does that sound to you? A bit of work, no potential income from it, and destruction of a major part of your business...

      This all lead to NSEC3,

      • Re: (Score:2)

        by Fastolfe ( 1470 )

        At the same time DNSSEC obsoletes SSL certificate authorities.

        DNSSEC only allows authentication of a hostname. It's more useful to be able to authenticate a domain name with a real-world identity, however, which still (today) relies on trusted third parties signing certificates with those real-world identities.

        This all lead to NSEC3, where you can sign each subdomain individually and thereby preserve the business model of charging each client.

        ??? NSEC3 is just an extension of NSEC (authenticated NXDOMAIN)

  • Young whipper-snappers! Back when I wanted a secure DNS server, I had to use djbdns! And this was before it was it was open-sourced, no apt-get or rpm -i for me. Why back in my days, you had to set your IP address yourself, none of this new-fangled DHCP.... mutter mutter Arcnet! mutter...

  • Three years to deploy RFC 4956 [faqs.org] is not "technical reasons"

Slashdot Top Deals

No spitting on the Bus! Thank you, The Mgt.

Close