ICANN and NIST Announce Plans To Sign the DNS Root 94
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."
Re: (Score:2)
Re: (Score:1)
Re:There is a curious lack of small DNSSEC resolve (Score:5, Informative)
Windows 7 and Windows Server 2008 R2 have one built in, and Unbound [unbound.net] is a smaller DNSSEC aware resolver for Unix like OSs.
Re: (Score:2)
Is that really not in Vista SP2? It has the same service pack as Windows Server 2008.
Re: (Score:1)
Re: (Score:1, Offtopic)
Fuck, as if Windows versioning wasn't confusing enough already. I guess I shouldn't be surprised, though. Windows 98 was the best version of Windows for a long time, and it had a second edition...
Re: (Score:2)
It's not new - the "R2" name was used for Win2003 already (so Win2003 SP2 and Win2003 R2 [wikipedia.org] were two different things). Though I agree it is unnecessarily confusing. My suspicion is that, unlike the tarnished Vista trademark, 2008 is generally viewed much more positively, and "all new and shiny" major releases are viewed more negatively when it comes to server software. So the naming approach is directly opposite to that of Windows 7 (which marketing clearly tries to distinguish from Vista) - "look, it's R2, i
Re: (Score:2)
Re: (Score:2)
Unbound is included in Fedora 10.
So "yum install unbound" gets it.
VeriSign (Score:5, Interesting)
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)
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)
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)
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)
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)
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:VeriSign (Score:5, Interesting)
they vouch for the fact someone had a credit card once and they got paid.
The processes that CAs go through before signing a certificate certainly should be a lot stronger, but the idea of a trusted certificate authority is still valid.
And some CAs are diligent...
The basic idea is valid, but the implementation sucks (and can probably only be made to not suck in a closed environment). Some CAs being diligent isn't enough, they all (well, all the ones trusted by any major browser) have to be diligent for the system to work at all. My choosing the best CA out there doesn't matter a bit, because they can't do anything to stop the worst from handing a phisher a cert for my domain.
Re: (Score:2)
And so what happens when there's a proxy authentication spoof....
The whole system goes to hell. A jerk-in-the-middle grabs the CA call, and says, yeah, sure, he's ok, and here's a hash to prove it. This means that the hash has to be checked, and authenticated *at the root server, itself an SOA* for each TLD request and update and so on. Bah. There has to be a better way.
Still, for those that don't want to pay a measly 50e for annual SOA tickling authority-- > let's route around them. There are so many po
Re: (Score:2)
The basic idea is valid, but the implementation sucks
Umm... Perhaps, but probably not in quite the way you suggest. The current implementation doesn't allow the user to distinguish between certs issued by CAs with smart, rigorous CPS's (you do know what that is right), and certs issued by CAs that only check e-mail to admin@ postmaster@,...
(and can probably only be made to not suck in a closed environment). Some CAs being diligent isn't enough, they all (well, all the ones trusted by any major browser) have to be diligent for the system to work at all.
Yeah. Which is why the major browsers require that the CAs be audited (and if they delegate to resellers the resellers too) to verify that they actually comply with what they say they'll do (their CPS), and that their CPS
Re: (Score:1, Interesting)
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...
Re: (Score:2)
You got a better idea? Maybe governments or domain registrars would sign certs?
Yes
Re: (Score:1)
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?
Re: (Score:2)
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)
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)
Re: (Score:2, Interesting)
Re: (Score:2)
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)
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)
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.
Re: (Score:2)
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)
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
Re: (Score:2)
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.
Re: (Score:2)
Re:Yeah, that'll help (Score:4, Interesting)
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?
Re: (Score:1)
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
SSL certs via DNS; trust is hard (Score:2)
"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
Re: (Score:2)
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
What does a domain get you? (Score:2)
"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
Re: (Score:2)
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
Re: (Score:2)
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
Re: (Score:2)
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
Identity and reputation go together (Score:2)
"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
Re: (Score:2)
Re: (Score:2)
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?"
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Re: (Score:1)
Re: (Score:2)
Domain dispute resolutions (Score:2)
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:
Re: (Score:2)
Whether that's Joe or not is not an addressed issue.
Re:Yeah, that'll help - really??? (Score:1)
Re: (Score:2)
On the other hand, won't DNSSEC and simple SSL make EV SSL certificates unnecessary?
No. The point of EV certs is to tie the site back to a real-world entity (like I understand "normal" certs were originally supposed to do). It's the difference between knowing that you really are talking to paypa1.com instead of an imposter (who could very well have registered the domain with false info, so you can't trust a whois lookup), and knowing that you really are talking to a site operated by PayPal, Inc, rather than one operated by phishers. Which can really be an important difference, given that '
Re: (Score:3, Informative)
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)
ICANN haz DNSSEC?
Us! (Score:3, Funny)
Re: (Score:1)
All your root are belong to us.
No, US.
DNSCurve (Score:3, Interesting)
I still think DNSCurve would have made more sense, http://dnscurve.org/dnssec.html [dnscurve.org]
Re: (Score:1, Funny)
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
the problem with securing DNS is the DNS is secure (Score:5, Interesting)
Re:the problem with securing DNS is the DNS is sec (Score:2, Informative)
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:
Re: (Score:2)
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.
Who holds the master key? (Score:5, Interesting)
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?
Re:Who holds the master key? (Score:4, Informative)
Re: (Score:2)
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.
Master key in multiple pieces (Score:2)
"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.
Re: (Score:1)
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)
Re: (Score:2)
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
Re: (Score:2)
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.
Re: (Score:2)
DNS queries shouldn't resolve significantly faster, except for the first DNS lookup performed for each TLD. The first time you look up a .com domain, sure, it takes an extra half a second to look up who's authoritative for .com, but for the next .com domain you want to look up, that's already cached.
Signed = value (Score:2)