Forgot your password?
typodupeerror
The Internet Security Technology

ICANN and NIST Announce Plans To Sign the DNS Root 94

Posted by timothy
from the no-more-absolute-value dept.
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."
This discussion has been archived. No new comments can be posted.

ICANN and NIST Announce Plans To Sign the DNS Root

Comments Filter:
  • VeriSign (Score:5, Interesting)

    by drDugan (219551) on Thursday June 04, 2009 @08:45PM (#28217213) Homepage

    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?

    I hope we do that again for DNS servers!

    </snark>

    But seriously, what's the busines model for maintaining the certs?

    • Re: (Score:2, Informative)

      by Anonymous Coward

      What's the business model?

      http://epic.org/privacy/dnssec/ [epic.org]
      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 [techworld.com]

      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 (Score:5, Informative)

      by Anonymous Coward on Thursday June 04, 2009 @08:55PM (#28217295)

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

        by cicuz (1414125)

        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 (Score:5, Informative)

      by Anonymous Coward on Thursday June 04, 2009 @08:56PM (#28217303)

      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?

      • Re: (Score:3, Insightful)

        by Anonymous Coward

        what moron modded "You pay verisign (or another trusted CA) to vouch for your secure content." as informative?

        they vouch for the fact someone had a credit card once and they got paid.

      • Re: (Score:1, Interesting)

        by Anonymous Coward

        I have an idea! We could sign the root with DNSSEC, then we wouldn't have any of those problems. Now, I wonder why no one else has thought of that.

        Oh, wait...

      • You got a better idea? Maybe governments or domain registrars would sign certs?

        Yes

      • by JanneM (7445)

        You got a better idea? Maybe governments or domain registrars would sign certs?

        Governments are the entities signing off on other forms of identification. So why not this?

      • You got a better idea?

        Yep. Once you've got DNSSEC you can publish a self signed cert in your DNS records (or public key or whatever standard people can agree on). Then you just need client support to fetch the details from DNS when connecting to the host over SSL.

      • Re:VeriSign (Score:5, Informative)

        by TheRaven64 (641858) on Friday June 05, 2009 @08:33AM (#28220799) Journal

        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.

    • Re: (Score:2, Interesting)

      by cdhgee (620445)
      You forgot your opening <snark> tag :-P
      • by drDugan (219551)

        LOL

        touché - fantastically self referential!

        However, literary expression and W3C validation result from different kinds of rule sets: the latter being rigidly logical, the former relying on implicit assumptions and unexplained connections to create an effect while the receiver parses the input.
        Or in short: that was a feature.

        It is this complexity: how breaking the rules in specific ways leads to effective results in a complex messy world that leads me to believe that even in the bast-case scenarios of t

  • Yeah, that'll help (Score:5, Informative)

    by QuantumG (50515) * <qg@biodome.org> on Thursday June 04, 2009 @08:56PM (#28217305) Homepage Journal

    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: (Score:3, Funny)

      by spinkham (56603)

      Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that "All the world's a Browser', and have no commerce with the benighted heathens who cling to this barbarous belief, that the days of thy network infrastructure may be long even though the days of thy current technology be short.

      Apologies to Henry Spencer.

      • by tepples (727027)

        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.

        Thou shalt foreswear, renounce, and abjure the vile heresy which claimeth that "All the world's a Browser'

        It doesn't matter. Grandparent's assertion should still hold even if you replace "browsers" with "client programs that your customers use to securely communicate with you".

        • Re: (Score:3, Informative)

          by spinkham (56603)

          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

    • by blueg3 (192743)

      Yes, that is exactly the problem signing the DNS root zone is solving -- SSL certificates.

      Pro tip: not all cryptographic and security systems on the Internet are necessarily SSL.

      • Can you say more? How does signing the root DNS solve the problems associated with SSL certs?
        • by AnyoneEB (574727) on Thursday June 04, 2009 @10:32PM (#28217793)

          If DNS is trusted -- that is, all data a client receives upon querying a domain's DNS record is trusted to be fully controlled by the owner of that domain -- then, theoretically, public keys could be stored there. That means that instead of getting an untrusted certificate from an HTTPS server which the user's browser has to examine for a signature from a trusted authority, the HTTPS server can simply say, "Hey, of course it's real: the fingerprint matches the one in my DNS record." without any external authority required (other than the one implementing DNSSEC, of course). That means once DNSSEC is implemented for the root and a site's top-level domain, the only part that needs to be trusted is the public keys of DNS root.

          That said, I have yet to see an implementation -- or even protocol specification -- of such a protocol. Does one exist or is this purely theoretical at this point?

          • by Kadin2048 (468275)

            There have been a bunch of proposals over the years to store public keys in DNS. Many of them are reflected in the list of DNS record types [wikipedia.org] over on WP.

            I recently heard some talk about the SSHFP record, but I don't know if any SSH clients actually try to retrieve or check it. (Right now with DNS not secured by anything it might be considered a security vulnerability, although I still think it would be better than the current system, where your SSH client throws a fingerprint at you and tells you to validat

          • "DNS is trusted ... then, theoretically, public keys could be stored there."

            That doesn't really address the original poster's objection to the current SSL PKI. DNSSEC is just lets resolvers be sure the DNS records they got are really the records from the publicly delegated nameservers. But the domain name registration process is even more wide-open than the SSL certificate process. People can register a domain name with no credentials at all. And changing the delegated nameservers generally just requires a username/password at the registrar; no cryptographically strong authenti

            • People can register a domain name with no credentials at all

              Well it does depend a fair bit on what you think the purpose of an SSL certificate is. I wouldn't expect the SSL cert to do anything more than verify that the site your connected to is, in fact, controlled by the person who registered the domain you're trying to connect to (in addition to allowing you to encrypt traffic). Not even in the ideal situation would I expect anything more than that.

              In my opinion, the only reason to have CAs at all instead of using self-signed certs is to prevent hacks that incl

              • "I wouldn't expect the SSL cert to do anything more than verify that the site your connected to is, in fact, controlled by the person who registered the domain you're trying to connect to..."

                Well, that would certainly justify putting SSL certs into DNS. But I have to wonder, what exactly does this get us, in practical terms? Anything at all? We've already established that merely registering an arbitrary domain is just about worthless, and that control of a particular domain is pretty weak. As a guess, I'd speculate it would be easier to hijack a domain from the registrar than it would be to intercept TCP connections to a web server. So I don't think SSL-certs-in-DNS would even be of much v

                • As a guess, I'd speculate it would be easier to hijack a domain from the registrar than it would be to intercept TCP connections to a web server.

                  You'd guess wrong. Without any kind of DNS signing or SSL certificate authorities, any router or DNS server that's being used in the transmission can basically be hacked to redirect traffic to an arbitrary server.

                  So here's a trivial example: I could set up an open wireless network next door to a coffee shop and assume some of the coffee shop patrons will stumble on it. Since I control the DHCP, I get to tell them which DNS server to use (or I can automatically reroute any traffic on the DNS ports to my D

                • Oh, and SSL certificate authorities do something to help the situation I laid out. Imagine the trick I described with DNS where it reroutes my traffic from citibank.com to some other web server pretending to be citibank.com. But instead of using http, I used https. Now what's going to happen?

                  Well the first thing is that the server is going to give me an SSL certificate that says, "I really am citibank.com, and you can check with Verisign to prove it." So now my browser sends that certificate to Verisig

            • by ??? (35971)

              In short, it's just some random operator on the 'net whose only real credential is they paid the fee needed to register a domain name (or SSL certificate).

              I see. You are under the illusion that an SSL cert (ought to) assert(s) meatspace identity (or identity other than "one who controls domain xxx.com." Perhaps that identity assertions other than those contained in cn or altSubjectName ought to have some meaning. Kinda what EV intends to do... for corp's.

              The real problem here is that "trust" is just a very hard problem. It's labor-intensive to establish trust. What should want? Two forms of ID? Credit references? Notarized forms? Personal appearance? Background check investigations?

              You are mixing / begging the question on a few concepts here, including:
              - granularity of identification
              - strength of identification verification
              - reputation

              Perhaps if these concepts were dealt with in an

              • "You are under the illusion that an SSL cert (ought to) assert(s) meatspace identity"

                I believe that SSL certificates that don't assert *something* about meatspace aren't worth the paper they're printed on.

                Yes, this means that I believe current SSL certificates are almost worthless. I was taking that as a given, and I think I made that clear enough.

                "You are mixing / begging the question on a few concepts here, including:
                - granularity of identification
                - strength of identification verification
                - reputation
                "

                Granularity of identification isn't really something I was thinking about here.

                Identification and reputation I do tend to consider together, mainly because identification without reputation isn't worth much, either. Nobody really cares that I'm

          • I see. That makes some sense. Thanks.
      • by QuantumG (50515) *

        Great, so take a system with the motto of "you got here first and have paid" and make it the basis of an identification system. Think about that. If you went to the DMV and said "Hey, can I have a license for 'Steve Jobs'?" should they reply with "Let me just see if that name is taken yet? Nope, here ya go!" or should they say "Are you Steve Jobs?"

        • Here in the Philippines if you slip a couple of thousand peso in with your handshake, you can be anyone you want, including I would hazard, Steve Jobs.

          If you don't want to do the whole 'bribery' thing, you can opt for the falsification of document pathway instead. Print out a new birth certificate from your laser printer right at home, then have it certified as a true copy by a notary public for about 200 peso at the Land Transportation Office itself. (LTO is the same as your DMV)

          But I get your point. We sh

          • by emj (15659)
            Yeah but can you get a passport that way, and can you get a work permit in another country using those credentials?
            • Thinking about this more seriously, I can't actually imagine why not. You can turn up to the births and deaths registry and simply say that you've never obtained a birth certificate. They have a window booth just for people in that situation. You provide whatever information you can, they charge you a little extra money (a late fee), and you get your birth certificate 30 minutes or so later. After this they do send the details to the national statistics office for entry in to their database, presumably this

              • Why would they need to verify your identities? When someone is born they can have whatever name their parents choose to give them. Since the mother gave birth in the hospital, the relationship of mother to baby was not in question and she was free to name the child whatever she wanted. The other details on the birth certificate pertaining to the child are things the hospital knows. I assume you're curious that under the lines for mother and father they just took whatever you said and were surprised at t
                • I don't know of many countries that outright let you 'make up' a last name though, apologies, that was really what I meant. Last names are usually always pretty static, obtained from either the mother or the father, but in our case nowhere along the chain did they check in to this. Your birth certificate is usually the starting point for all your official forms of documentation, including passports. I guess my point is that it wouldn't be hard to have many identities here.

                  The Australian government wanted to

        • If you went to the DMV and said "Hey, can I have a license for 'Steve Jobs'?" should they reply with "Let me just see if that name is taken yet? Nope, here ya go!" or should they say "Are you Steve Jobs?"

          The TLDs have dispute resolution policies [icann.org] for that sort of thing. Here's how it normally works:

          1. Example Inc. applies for a trademark registration on EXAMPLE for some sort of good in a developed country.
          2. Realemain LLC registers the domain EXAMPLE.COM without having registered a trademark for EXAMPLE in any field of goods and services.
          3. Realemain puts EXAMPLE.COM up for sale or uses the domain for a confusing purpose.
          4. Example Inc. discovers this and builds a case for Realemain's bad faith and presents it to a WI
    • Identity verification is a non-goal of SSL. The purpose of having a cert signed is so that someone receiving a cert claiming to be from http://joessite.com/ [joessite.com] can be sure it's actually from the person who controls joessite.com, and not someone trying to MITM you.

      Whether that's Joe or not is not an addressed issue.
    • Re: (Score:3, Informative)

      by ??? (35971)

      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 Slashdo

  • ICANN? (Score:5, Funny)

    by InsertWittyNameHere (1438813) on Thursday June 04, 2009 @09:00PM (#28217327)

    ICANN haz DNSSEC?

  • Us! (Score:3, Funny)

    by SEWilco (27983) on Thursday June 04, 2009 @09:35PM (#28217531) Journal
    All your root are belong to us.
  • DNSCurve (Score:3, Interesting)

    by Helios1182 (629010) on Thursday June 04, 2009 @09:43PM (#28217583)

    I still think DNSCurve would have made more sense, http://dnscurve.org/dnssec.html [dnscurve.org]

    • Re: (Score:1, Funny)

      by Anonymous Coward

      Hi Dan,

      Sorry, I don't think it will work out.

      -Everyone

    • Re: (Score:3, Insightful)

      I still think DNSCurve would have made more sense, http://dnscurve.org/dnssec.html [dnscurve.org]

      DNSSEC certifies the data, while DNSCurve only certifies the connection between the DNS server and the resolver.

      With DNSSEC, you know that the DNS records you receive are correct.

      With DNSCurve, your ISP's caching resolver knows that it is talking to the proper DNS server. You do not know that you are talking to your ISP's resolver instead of an imposter, and you do not know if your ISP is forwarding the records accurately.

      DNSSEC can be used for interesting things like distributing public keys. DNSCurve can

  • by wayne (1579) <wayne@schlitt.net> on Thursday June 04, 2009 @09:45PM (#28217593) Homepage Journal
    The big problem with DNSSEC, if widely used, is that it prevents forgery of DNS responses. ISPs and internet cafes will not like this, since that means they can no longer forget DNS replies to missing domains or to force people through registration pages. I can see a *LOT* of push-back from having end-users using DNSSEC.
    • by 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: (Score:3, Informative)

        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 [rfc-archive.org] (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 relationship

        • by Chyeld (713439)

          If the only thing you can talk to (prior to being 'registered') is the ISP's servers, then it is trivial for the ISP to sign everything. All your IP are belong to the ISP, all your traffic goes to the server they send you to.

  • by karl.auerbach (157250) on Thursday June 04, 2009 @09:49PM (#28217615) Homepage

    Who will be the person who gets to hold the master crypto keys used to sign the root zone?

    Somebody, somewhere, has to do this. Who?

    • by papafox_too (883077) on Thursday June 04, 2009 @10:25PM (#28217767)
      Homeland Security demanded (and subsequently received) a copy of the root DNSSEC master keys [theregister.co.uk] from ICANN. They presumably want them so that they can perform man-in-the-middle attacks against any .com/.net/.org domain.
      • I see the "demanded" part, but I don't see any evidence of the "subsequently received" part.

        By-the-way, when I asked "who" I was thinking that there will be some institutional thing with the keys locked away in some vault that requires multiple people to agree to open.

        But those people will work at the behest of somebody and, after watching president Nixon knock off Attorney General after Attorney General during the Saturday Night Massacre, I tend to wonder about the extreme limiting cases.

        • "By-the-way, when I asked "who" I was thinking that there will be some institutional thing with the keys locked away in some vault that requires multiple people to agree to open."

          Even better is when the master key is split into multiple pieces. Each piece is independently encrypted and then stored in a physically secure location. Each piece/location gets a different person.

          VeriSign claims this is how they protect their master keys, FWIW. I'm not sure I believe them.

    • Who will be the person who gets to hold the master crypto keys used to sign the root zone?

      Somebody, somewhere, has to do this. Who?

      ...Gandalf and Elrond look pointedly at Frodo...

  • So what? (Score:3, Insightful)

    by damn_registrars (1103043) <damn.registrars@gmail.com> on Thursday June 04, 2009 @09:58PM (#28217639) Homepage Journal
    They can take all the measures they want to secure the root, if they keep letting unscrupulous registrars sell domains it all will be for naught anyways. Wake me up if they ever decide that for some reason they feel security and stability are suddenly more important than profit.
    • by hedwards (940851)
      I don't agree with that, what this sort of thing does is ensure that you're being directed to the correct site. Meaning that if you think you're logging into your bank's URL, you can be assured that it's going to the correct IP address. The site would still need to be secured beyond that, but it makes it a lot tougher to phish.

      The issue of how domains are sold, is really a completely different matter. While that is important, it's not really that important while we're running around not necessarily knowi
    • by Phroggy (441)

      They can take all the measures they want to secure the root, if they keep letting unscrupulous registrars sell domains it all will be for naught anyways. Wake me up if they ever decide that for some reason they feel security and stability are suddenly more important than profit.

      DNSSEC won't reduce spam, but it will help to solve other problems.

  • They're going to start signing them! Awesome. Signed things automatically double in value. I'm going to get a bunch of them now, then hold onto them until ICANN and NIST die. Then they'll double in value again, and I'm in the profits!

/earth: file system full.

Working...