ICANN and NIST Announce Plans To Sign the DNS Root

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

Comments

There is a curious lack of small DNSSEC resolvers

[Anonymous Coward]

...or am I just not seeing the forest for the trees? There's BIND, but that seems a little excessive for a personal recursive resolver. The small ones don't seem to even have DNSSEC support on the short term agenda. What to do?

VeriSign

[drDugan]

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:VeriSign

[Anonymous Coward]

What's the business model?

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

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

[Anonymous Coward]

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:VeriSign

[Anonymous Coward]

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:VeriSign

[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:VeriSign

[Anonymous Coward]

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

Re:VeriSign

[Timothy Brownawell]

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:VeriSign

[Anonymous Coward]

what happens when those that OWN the CA servers decide that DNSSEC is not a valid alternative. i wonder?

maybe this would be an *opportunity* for those in opposition to VRSN owning it all to comment?
_time-elapsed_
oops, just checked the ntia site and apparently folks did, only ntia did not listen!

Re:VeriSign

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

Re:VeriSign

[GodfatherofSoul]

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

Yes

Re:VeriSign

[postbigbang]

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 poisoning problems, (d)DoS attacks, and plan fudgery that it's a freaking wonder than DNS hasn't been shot dead long ago. And don't get me started on BIND.

Re:VeriSign

[JanneM]

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:VeriSign

[complete loony]

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

[cicuz]

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

[Anonymous Coward]

That is certainly not epic, not in the slightest.

Re:VeriSign

[TheRaven64]

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:VeriSign

[???]

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 meets a minimal set of standards.

It seems your argument really boils down to: there has been a race to the bottom on the documented signing policies in order to minimize costs because higher cost, more rigorous validation mechanisms can't be used to differentiate a cert in the marketplace. (Except EV, but that's a whole other story)

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.

And they can't do anything to stop the best from handing a phisher a cert. However, the browser producers require an audit (which serves as a detective and preventive control) to verify that appropriate and sufficient processes are in place to ensure that a) the CPS is followed and b) the CPS meets a (minimal) set of rules.

Now, all this means that when (as a user) you're presented with a cert [that is not EV], you can be strongly assured that at some point, that cert was issued to someone who could read and respond to mail at an administrative email account for that domain. Is this sufficient for the user? Maybe. If it's a forum site, or a blog site, then probably. If it's an eCommerce or online banking site, probably not.

The browser makers need to allow:
a) Certs with differing validation methods to be differentiated (on a finer granularity than EV / not EV)
b) Client-side policy to be implemented on the basis of that differentiation

In order to arrest this race for the bottom and competition solely on price by the CAs.

Incidentally, both of these can be achieved within the current CA infrastructure...

Re:VeriSign

[cdhgee]

You forgot your opening tag :-P

Re:VeriSign

[drDugan]

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 the soon impending artificial intelligence technology explosion, good ole' wet human reasoning still has a long foreseeable future of value.

Re:There is a curious lack of small DNSSEC resolve

[Anonymous Coward]

Become an anonymous coder?

Yeah, that'll help

[QuantumG]

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:Yeah, that'll help

[spinkham]

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:Yeah, that'll help

[Anonymous Coward]

That's off topic, isn't it? Anyway, DNSSEC has the potential to replace these certificates which only prove that you control the domain, and it will do it for free. So yes, that will indeed help.

(If you're wondering how: DNSSEC establishes a trust hierarchy, just like the trust hierarchy of SSL certificate authorities. This enables DNS to deliver authenticated public keys which could be used for SSL connections, replacing the keys in SSL certificates.)

Re:Yeah, that'll help

[blueg3]

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:Yeah, that'll help

[nine-times]

Can you say more? How does signing the root DNS solve the problems associated with SSL certs?

Re:Yeah, that'll help

[QuantumG]

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:Yeah, that'll help

[AnyoneEB]

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:Yeah, that'll help

[Kadin2048]

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 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 validate it -- which of course next to nobody actually does.)

I think the record you'd want to use is probably the "CERT" one, although that may be used or is intended for use by PGP, I'm not sure.

Re:Yeah, that'll help

[Anonymous Coward]

There are I-Ds for SSLFP/TLSFP record types. I haven't personally looked into them though.

Re:Yeah, that'll help

[digitalchinky]

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 should pick the latter, but we are mostly lazy creatures :-)

Re:Yeah, that'll help

[emj]

Yeah but can you get a passport that way, and can you get a work permit in another country using those credentials?

Re:Yeah, that'll help

[digitalchinky]

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 is used as part of the immigration process, but it's already too late by this stage.

I have an Australian passport so I'm not in any desire to actually do this, though one point of interest: My daughter was born here, nobody, not a single person, ever asked for our identities. The hospital asked us for a name, then went off and typed up exactly what we wrote down. We took their form and used it to get a birth certificate. I suspect they just assume the hospital would verify our identities first.

An interesting country.

Re:Yeah, that'll help

[Late Adopter]

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/ 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:Yeah, that'll help

[michaelwv]

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 that, but in most applications that's not really important. It may be later if your daughter wants to claim Australian citizenship by right of parentage, but mostly birth certificates are used to certify that someone was born in a particular place on a particular date. The hospital had no doubts on those points.

Re:Yeah, that'll help

[Anonymous Coward]

SSL certificates were supposed to prove that the owner of the corresponding private key is indeed the person (or legal entity) listed in the certificate. That is not the same as being in control of the domain. Nowadays most SSL certificates just prove that the owner of the corresponding private key was at some point able to receive mail sent to a restricted account under that domain. There still is a need to prove that "Joe is Joe, not just somebody with access to Joe's domain" and the product which supposedly proves it is called "extended validation certificates". (Just in time, because DNSSEC will make simple SSL certificates which just prove domain access obsolete...)

Re:Yeah, that'll help

[nine-times]

I see. That makes some sense. Thanks.

Re:Yeah, that'll help

[???]

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 Slashdot. Why post based on relevant facts rather than baseless, off-topic innuendo?

Re:Yeah, that'll help

[tepples]

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:Yeah, that'll help

[spinkham]

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 be assigned to a user. I can't request slashdot.org from a vendor and get it. If someone owns a domain name, only that particular registrar has the power to change the domain name. So if I choose a reputable registrar, I'm covered.

By contrast, I can request an SSL cert from any provider on the planet. If I already own a SSL cert, a company doesn't have to check a master registry before they issue another cert.

In effect, with DNS, the defender choose the battleground by choosing the most secure registrar. With SSL, the attacker chooses the battleground by choosing the least secure certificate authority.

Re:Yeah, that'll help

[digitalchinky]

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 see everything when I registered her citizenship. :-) It's not a smooth (or cheap) process by any means.

Re:There is a curious lack of small DNSSEC resolve

[spinkham]

Windows 7 and Windows Server 2008 R2 have one built in, and Unbound is a smaller DNSSEC aware resolver for Unix like OSs.

ICANN?

[InsertWittyNameHere]

ICANN haz DNSSEC?

Re:ICANN?

[Anonymous Coward]

If I hadn't lost my mod privileges for being pro microsoft (even with excellent karma), I would have modded you up.

Gold.

Us!

[SEWilco]

All your root are belong to us.

Re:Us!

[mindcorrosive]

All your root are belong to us.

No, US.

DNSCurve

[Helios1182]

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

Re:DNSCurve

[Anonymous Coward]

Hi Dan,

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

-Everyone

Re:DNSCurve

[Timothy Brownawell]

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

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 cannot, because it still requires you to trust your ISP and your ISP's network. (Or alternatively it would require that shared caching resolvers not be used, which would cause a major increase in traffic to the authoritative servers.)

Re:DNSCurve

[Anonymous Coward]

Yeah, those are trade offs in the approaches each take. But don't forget some other things: DNSSEC still makes you dependent upon the root and TLD servers being secure (e.g., Verisign has been fooled into signing fake "Microsoft, Inc." ActiveX keys before), and the semantics are a lot more difficult to work out for DNSSEC scenarios (seriously, join the namedroppers mailing list: they're still arguing about what clients should do in different scenarios, and every implementer has a different opinion).

DNSCurve's semantics are much simpler (just throw away forged packets), and it's very simple to implement (I wrote to add support for it to djbdns's dnscache in less than 500 lines). Also, it only adds about 50 bytes of overhead to packets using the streamlined format, whereas DNSSEC adds about 128 to 256 bytes per record set (and most authoritative responses include several record sets).

Finally, keep in mind that DNSCurve and DNSSEC aren't incompatible. Servers and caches can support both.

the problem with securing DNS is the DNS is secure

[wayne]

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.

Who holds the master key?

[karl.auerbach]

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?

[papafox_too]

Homeland Security demanded (and subsequently received) a copy of the root DNSSEC master keys from ICANN. They presumably want them so that they can perform man-in-the-middle attacks against any .com/.net/.org domain.

Re:Who holds the master key?

[karl.auerbach]

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.

Re:Who holds the master key?

[Anonymous Coward]

Ooooo, oooooo! Me! Can I hold them?!

Re:Who holds the master key?

[BaseSequence]

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?

[damn_registrars]

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.

Re:So what?

[hedwards]

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 knowing that we're on the correct server.

Re:So what?

[Phroggy]

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:the problem with securing DNS is the DNS is sec

[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:There is a curious lack of small DNSSEC resolve

[drinkypoo]

Is that really not in Vista SP2? It has the same service pack as Windows Server 2008.

Re:the problem with securing DNS is the DNS is sec

[Timothy Brownawell]

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 (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 relationships between the zone administrators and the stub resolver itself.

(a "stub resolver" being the system library that implements getaddrinfo() and friends)

Re:There is a curious lack of small DNSSEC resolve

[jisatsusha]

Windows Server 2008 is based on Vista, whereas R2 is based on Windows 7.

The root zone is already signed

[Anonymous Coward]

You can already download the root zone from http://www.internic.net/domain/, verify its GPG signature, and then configure your DNS cache to use the file instead of contacting the root servers. Just setup a cron job to automatically update and re-verify the file once a month. DNS queries will even resolve faster because you won't have to contact the root servers!

Re:The root zone is already signed

[Phroggy]

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.

Re:The root zone is already signed

[Anonymous Coward]

Sure, it's not a very impressive time difference, but the root servers are already heavily overloaded and frequently targeted by DoS attacks, so the less you have to depend on them, the better.

Re:There is a curious lack of small DNSSEC resolve

[afidel]

2008 R2 is based on the Win7 codebase.

Re:There is a curious lack of small DNSSEC resolve

[drinkypoo]

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:There is a curious lack of small DNSSEC resolve

[shutdown -p now]

It's not new - the "R2" name was used for Win2003 already (so Win2003 SP2 and Win2003 R2 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, it's pretty much the same... just better".

Thanks to all ya'all for making it happen.

[Anonymous Coward]

Good to see the USoA has, as usual, ignored all complaints from everywhere else (the world population is 300-odd million and some scary brown people in a desert somewhere, right? right?) and is going right ahead breaking one more promise, this time not to meddle with everyone's internet.

Thanks to all ya'all for making it happen.

Master key in multiple pieces

[DragonHawk]

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

SSL certs via DNS; trust is hard

[DragonHawk]

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

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

Don't get me wrong, SSL certs in DNSSEC does have some applications, especially for those who don't have a need for strong authentication but would would still like some basic crypto on general principles.

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?

The idea of "Extended Validation" SSL certificates seems like it might be a step in the right direction here, but I'm far from convinced it's actually going to prove in practice to be significantly better than "regular" SSL certificates.

Further, delegating the privilege of granting trust -- i.e., trusting someone else to establish trust for us, which is what we do with VeriSign, et. al. -- is that much harder. Now we're trusting a company -- whose interests aren't necessarily coincident with ours -- to authenticate others for us.

Re:SSL certs via DNS; trust is hard

[nine-times]

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 include rerouting traffic to a phony address, man-in-the-middle attacks, and stuff like that. But you're suggesting that they should also vouch for the trustworthiness of the person who owns the domain? And then what are the criteria for that? How trustworthy do I have to be? Lots of people here on Slashdot don't think Microsoft is trustworthy-- do they get to keep their domain?

Re:SSL certs via DNS; trust is hard

[???]

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 orderly, separate manner, the question of trust would be more easy to quantify and address.

Now we're trusting a company -- whose interests aren't necessarily coincident with ours -- to authenticate others for us.

Trust but verify. They publish a statement with respect to the policies and procedures that they follow. They are audited to ensure they follow those policies and procedures. It is up to us (and the browser makers [?]) to ensure that those policies are sufficient for our purposes.

Re:There is a curious lack of small DNSSEC resolve

[hey]

Unbound is included in Fedora 10.
So "yum install unbound" gets it.

Signed = value

[halcyon1234]

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!

Re:First root

[FredFredrickson]

You know what would fix the "first post syndrome? Just a simple word count requirement with a count-down timer and a filter for particular words.. if any variation of URLS or FIRST or FROSTY PISS show up, it requires you to wait 2 minutes before submitting. It would be a gamble, and you would unlikely end up the first post troll- and it would cut down on the desire to do it, since it's rarely possible. More often relevant posts would end up #1, even though they clicked submit later.

Thank you

[Anonymous Coward]

this finally explains the nugget behind why DNSSEC is interesting: using secure DNS for public keys

((MOD PARENT UP))

Re:Thank you

[Shatrat]

sudo mod parent up

Re:Thank you

[Anonymous Coward]

PARENT mod UP radix 36 = H8 radix 36 = 620 decimal

Re:the problem with securing DNS is the DNS is sec

[Chyeld]

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.

Domain dispute resolutions

[tepples]

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 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 WIPO arbitration panel.
5. WIPO finds in favor of Example Inc. and orders the registrar to transfer EXAMPLE.COM to Example Inc.

In addition, new TLDs often have a "sunrise" period, in which entities need to submit proof of trademark registration in order to register a corresponding domain, before the TLD goes live.

Re:Yeah, that'll help - really???

[stine2469]

On the other hand, won't DNSSEC and simple SSL make EV SSL certificates unnecessary?

Re:Yeah, that'll help - really???

[Timothy Brownawell]

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 '1' and 'l' (and several other pairs) tend to look alike in many fonts.

Some possible problems

[jwkckid1]

Two possible if no likely soon to be recognized problems with this plan. First Verisign, once owned by Networksolutions will be the signing authority for the root servers it currently manages under contract for the USG, and second NIST's recently released standard for signing of these certs for DNSSEC are well known to be weak amongst security professionals like myself. Jeffrey A. Williams CSO/DIR. Internet Network Eng. SR. Eng. Network data security IDNS. div. of Information Network Eng. INEG. INC. ABA member in good standing member ID 01257402 E-Mail jwkckid1@ix.netcom.com My Phone: 214-244-4827

Re:First root

[ibsteve2u]

I'm glad there is a scientific basis for me not having to inflict my root on everybody.

What does a domain get you?

[DragonHawk]

"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 value to the small-time, private domain holder.

To be clear: I don't see significant value in current SSL certificates, either. It seems like mostly security theater to me. Lots of crypto is done, and lots of money changes hands, but is anything made significantly more secure?

Re:What does a domain get you?

[nine-times]

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 DNS server). So once I control the DNS responses, when they type "citibank.com" into their browsers, their system does a DNS query to find the IP address and my DNS server gives them the IP address of the server I've made up to look like citibank.com. However, my site just takes whatever password information they type in and then gives them an error message, "Sorry, our site is down right now. Please try again later." The user goes on about his business, and meanwhile I have access to his bank account.

But even ignoring this simple little DNS trick, it's entirely possible to just have the router itself reroute traffic. I could set my router so that any traffic directed to 74.125.127.100 (google.com) instead gets sent to 207.46.104.147 (bing.com). It's really not difficult. That's way easier than hacking Google's registrar and changing the real DNS records.

Re:What does a domain get you?

[nine-times]

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 Verisign and asks, "Citibank.com says that this certificate is proof that they're really citibank.com. Is this legit?" Now because the fake server can't generate a bogus certificate that will fool Verisign, Verisign looks at it and says, "No, this isn't legit." The browser throws up a big warning, and if the user is savvy at all, they'll know not to put in their login credentials.

Now if you're clever, you might think, "Well wait a second, if my browser doesn't know which certificates are valid without checking with Verisign, then why doesn't the hacker just reroute the traffic to Verisign to his own server? Couldn't he then have his own server just say that every certificate is valid?" That would work, except that your browser is distributed with a certificate for Verisign. Because of that, unless the hacker can compromise your browser locally (in which case you're screwed no matter what), your browser can't be fooled into thinking it's talking to Verisign.

So all in all, that's a pretty good system. There's only one piece where it's likely to fall apart, and that's if the certificate authority (Verisign in this case) can be tricked into issuing a valid certificate to someone who doesn't own the domain. Putting SSL certs in DNS could help this problem.

But ignoring that little problem, SSL certificates prove pretty well that when I go to visit "citibank.com" that I'm actually connecting to "citibank.com". Knowing that "citibank.com" is actually owned by Citibank whereas "citibanking.com" isn't... well, that's another problem, but a far less dangerous one.

Identity and reputation go together

[DragonHawk]

"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 "Benjamin Scott". What matters is what my name stands for. Do I keep my word? Do I pay my debts? And so on. Even if it's a matter of individual, one-on-one exchanges. You trust your friends/associates because they've proven to be trustworthy, not because you recognize their face.

A domain name without a reputation is worthless for the same reasons.

This holds even if we want to postulate the idea that an "anonymous" entity can prove itself trustworthy over time though its behavior, a la the cypherpunk wet dream. In that case, the anonymous entity itself becomes identity and reputation. We don't need a CA to validate that; the self-signed certificate we got back on day one is good enough.

To reiterate and summarize: A CA PKI without a mechanism for validating identity/reputation is worthless.

"It is up to us (and the browser makers [?]) to ensure that those policies are sufficient for our purposes."

I guess I would have to suppose that current policies are not sufficient for any practical purpose.