Posted
by
kdawson
on Tuesday February 24, 2009 @06:23AM
from the kicking-the-dragging-feet dept.

alphadogg writes "Last fall, the US government sought comments from industry about how better to secure the Internet by deploying DNSSEC on the root zone. But it hasn't taken action since then. Internet policy experts anticipate further delays because the Obama Administration hasn't appointed a Secretary of Commerce yet, the position that oversees Internet addressing issues. Meanwhile, the Internet engineering community is forging ahead with a stopgap to allow DNSSEC deployment without the DNS root zone being signed. Known as a Trust Anchor Repository, the alternative was announced by ICANN last week and has been in testing since October."

To the contrary, DNSSEC could possibly kill the goldmine that is the SSL cert racket. That is, unless having your DNS entry signed somehow becomes a "value added" service you need to pay for extra.

I'm a layman here, but glancing at how DNSSEC works, I see no obvious way selectively signing some but not the rest of entries could work. This means, DNSSEC would provide a more secure way to give the public key to a viewer.

Instead of proving that the server's owner paid a sum to the CA, it would prove that the server's owner has control over the DNS entry.

If the above is correct, that's a good explanation why we don't have DNSSEC yet -- it would have a potential to kill the CA's income.But if there is a way to selectively skip signing certain DNS entries, all your fears would be true.

To the contrary, DNSSEC could possibly kill the goldmine that is the SSL cert racket. That is, unless having your DNS entry signed somehow becomes a "value added" service you need to pay for extra.
I'm a layman here, but glancing at how DNSSEC works, I see no obvious way selectively signing some but not the rest of entries could work. This means, DNSSEC would provide a more secure way to give the public key to a viewer.

You may be a layman, but you appear to have far more clue about this stuff than most.
Yes, once DNSSEC [wikipedia.org] is deployed, anyone with a domain name can publish CERT records [wikipedia.org] and have about the same security as a paid-for CERT. Granted the cert authorities right now require you to give your name and address and such, which publishing CERT records in the DNS won't require so they aren't exactly the same, but close enough considering how little checking the cert authorities do on such information

"This theoretically enables the domain owner to publish his SSL certificate as a DNS record, sidestepping the whole SSL certificate authority hierarchy and the associated fees"In that case if someone does an MITM (or other) attack, how do you know the published SSL cert in a DNS record is really the genuine cert?

After all during the attack, the attacker could publish his own SSL cert as a DNS record. The attacker can pretend to be the dns server as well as the webserver or other server the victim is going t

DNSSEC does not encrypt DNS responses, but it authenticates them. That's the whole point.

If your browser connects to slashdot.org, the root server will reply with records which are signed with the private root key. The public key for the org domain is one of those records. Your computer verifies the records with the public root key, which is stored in the resolver configuration. The org server will respond with records which are signed with the private org key. The public key for the slashdot.org domain is

"This theoretically enables the domain owner to publish his SSL certificate as a DNS record, sidestepping the whole SSL certificate authority hierarchy and the associated fees"

In that case if someone does an MITM (or other) attack, how do you know the published SSL cert in a DNS record is really the genuine cert?

Same way you know that a cert is genuine in SSL: a chain of trust. The browser will come hardcoded with a handful of root certs. Any certificate that's not signed (directly or indirectly) by a root certificate will be ignored. Only a very limited number of parties, perhaps domain name registrars, would be able to sign functional certificates. Therefore you can't forge a DNSSEC certificate unless you can compromise one of these small number of keyholders, which is likely to be difficult, and which can be

All possible in principle, but whether it happens in practice depends on who does the signing. The scenario you describe could perfectly well happen right now with DNS. The root registrar (ICANN) could charge an exorbitant sum of money to be the.com registrar, maybe selling it to the highest bidder with no strings attached; and then the.com registrar (VeriSign or whoever) could charge $1000/year for all.com domain names. But this hasn't, in fact, happened. If the root certifier for DNSSEC is ICANN, w

Well I said "proper" for a reason, and I should've clarified but didn't. I meant a properly validated cert that actually means something beyond "yeah, your communications with this site are encrypted and probably won't be hijacked."

Personally, I only truly respect secure websites that require client certificates as well.

To the contrary, DNSSEC could possibly kill the goldmine that is the SSL cert racket. That is, unless having your DNS entry signed somehow becomes a "value added" service you need to pay for extra.

SSL also protects against other threats, such as route poisoning and eavesdropping, neither of which are DNS-related threats. To say that DNSSEC replaces all that is just plain wrong.

If you think that the commercial CAs are running a racket, you don't need to take part. Really. FWIW, I use SSL with a custom CA just fine across some of the servers I look after; we can just distribute the CA certificate manually just fine too, since it is a limited problem space. For your own stuff, that's actually ideal sinc

SSL also protects against other threats, such as route poisoning and eavesdropping, neither of which are DNS-related threats.

No one is talking about replacing SSL. It's about replacing the way you receive the server's public key.

Currently, the key is provided by the very server you're connecting to, with the only assurance the key is kosher being a signature of a CA on the key. The CAs will happily sign any key if they are paid. In theory, they are supposed to verify the name attached to the key, but that theory has nothing to do with practice.

If you think that the commercial CAs are running a racket, you don't need to take part.

Ok, then try using a self-signed certificate. That would be strictly better than pl

"That's how DNSSEC works. The root cert is used only to validate the keys for.com,.gov,.pl,.uk... Then, the key for.org will sign slashdot.org, without the root cert having anything to say."OK let's assume the root cert doesn't have anything to say.

But you should go to the next obvious step/question: How much will the entities holding the.com and.org keys charge for signing cnn.com, slashdot.org and so on?

Free? Really?

As I've said, DNSSEC is not about security it's about creating a way to collect mo

But you should go to the next obvious step/question: How much will the entities holding the.com and.org keys charge for signing cnn.com, slashdot.org and so on?

Presumably, exactly the same amount they currently charge for those domain names. Isn't the idea to make it the standard, so that whenever you buy a domain name you also get whatever signatures/keys/etc you need to be able to make dnssec work on your domains?

1) If you are using https/ssh/ipsec/openvpn properly, and someone spoofs your dns so you attempt to connect to the wrong server, you will get a warning/error. So what is DNSSEC's added value here?

Or you'll just get an unencrypted page and no error, and only notice if you're actually paying attention.

So someone tell me, what real value does DNSSEC add?

It prevents spoofed DNS responses, even if there is a mitm. This means that you can use DNS for public key distribution (so there's no reason to eve

f you think that the commercial CAs are running a racket, you don't need to take part. Really. [...] You only need the CAs when you are communicating with people who don't already know you

So you do have to take part, because the browser makers have decided that self-signed SSL is deserving of error messages due to being somehow less secure than plain http. Therefore making it a "racket" instead of just a "scam".

So you do have to take part, because the browser makers have decided that self-signed SSL is deserving of error messages due to being somehow less secure than plain http. Therefore making it a "racket" instead of just a "scam".

No, browser makers have decided that certificates not added to their 'trusted' certificate list are deseerving of error messages due to it being the way encrypted communications are supposed to work.

No, *encrypted* doesn't mean *authenticated*. The fact that the browsers fail to make this distinction is no excuse for treating encrypted but unauthenticated connections as inferior to connections with neither encryption nor authentication. Having an encrypted, unauthenticated connection is strictly more secure than not using SSL at all -- even in a worst-case scenario when you're subject to a MitM attack, your traffic is still only readable by the attacker, rather than by everyone along the transit path.T

I understand why we didn't start with SSL as the default 15 years ago, but we could fix that now.

Computational costs for SSL are apparently not trivial, from what I've been told. Moreover, any kind of encryption completely kills caching proxies, which are essential to performance for a lot of large sites. Wikipedia uses Squids that can serve 3000 req/s per server easily on cache hits. The reason they can do this is because once the cache entry is located, it's simply a matter of instructing the OS to copy a string of bytes from a memory address to a network port and close the connection. There's no

f you think that the commercial CAs are running a racket, you don't need to take part. Really. [...] You only need the CAs when you are communicating with people who don't already know you

So you do have to take part, because the browser makers have decided that self-signed SSL is deserving of error messages due to being somehow less secure than plain http. Therefore making it a "racket" instead of just a "scam".

It's not a scam. It would just be plain stupid to accept an SSL certificate that was signed by anyone. Just because a site says "Hi, I'm eBay!" doesn't mean that it is. CAs sign the certificate as "proof" that it is really eBay.

It's not a scam. It would just be plain stupid to accept an SSL certificate that was signed by anyone. Just because a site says "Hi, I'm eBay!" doesn't mean that it is. CAs sign the certificate as "proof" that it is really eBay.

No. It would be stupid to give all the special UI cues for a secure site, with an unverified certificate. SSL with an unverified certificate is approximately as secure as plain http with no encryption, and should be treated the same. (And "signed by any random CA, maybe even a different one than last time" should not be the same as "verified", but that's a different stupidity...)

Signed zone data is not reliant on x509 certificates; algorithms defined in RFC 4034 are RSA/MD5, Diffie-Hellman, DSA/SHA-1, Elliptic Curve, RSA/SHA-1, and room for ~245 future algorithms. There is no identity information stored in the keys used for DNSSEC, so you should be able to generate the keys yourself.

Re Verisign. If the US government is sincere about listening to the public, the overwhelming majority of comments were fine with just having ICANN "sign the root" leaving Verisign (0 votes) out of the equation. Listening to the global Internet community would be a big step by the new Administration toward rebuilding America's reputation overseas.

Re Verisign. If the US government is sincere about listening to the public, the overwhelming majority of comments were fine with just having ICANN "sign the root" leaving Verisign (0 votes) out of the equation. Listening to the global Internet community would be a big step by the new Administration toward rebuilding America's reputation overseas.

As I understand it, the overseas opinion is that Americas 'reputation overseas' was destroyed when that 'crook' Bush 'invaded' Iraq.

So you're telling me those same nutjobs are suddenly going to forgive America because some low-level dork in a new administration signs the DNS root?

> As I understand it, the overseas opinion is that Americas 'reputation overseas' was> destroyed when that 'crook' Bush 'invaded' Iraq.

No. said "reputation" was "destroyed" when Bush was classified as "right wing" (not that they weren't justified in being cautious during the eight years that the White House was occupied by the stupidest man to ever serve as President).

> So you're telling me those same nutjobs are suddenly going to forgive America because> some low-level dork in a new administra

the White House was occupied by the stupidest man to ever serve as President

Do you have any concrete evidence to back up this assertion? I'm pretty sure a lot of past presidents have been characterized as idiots by their political opponents. On the other hand, while you might not have to be a genius to get a BA from Yale and an MBA from Harvard, I'd imagine it would be fairly hard if you're genuinely stupid.

Apart from the certificate trust scam ("trust us, for you give us money"), too many non-us governments (and non-us non-governmental people, natural or otherwise), won't accept a us govt held root. And why should they?

Yes, arguably a fragmented root it not as good as it should be, but a root held by a single entity, especially one as "trustworthy" as the one with the power to push this through, might, in the long or not so long term, easily cause a plethora of split DNS universes. Which is lots worse.

It really is too bad that the most vocal people with the technical knowledge to understand the impact choose to ignore the politics involved. Yes, smart move people, that will make the issues go away real good.

I think a fragmented root is ideal, as long as its clear who you are trusting i would rather have the EU sign off on some, US on others, Russia/china on theirs, there is no need to get everything signed by the US (in fact politically AND technically it is a much worse solution).

Is there some reason they can't just put multiple signatures on the records, so the US, Russia, China, etc, could all sign the entire root if they wanted to?

DNSSEC rely on having a central "trusted" authority to sign all the dns keys. Not even speaking about the inherent security issues with this model, that means that everyone will depend on a single authority for name resolutions (sure Network Solutions loves this)

DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.

DNSCurve is interesting technology, but it has many problems, not the least of which is that it is mostly hype right now. It does not really replace DNSSEC [wikipedia.org] in functionality, but rather, it is closer to TSIG [wikipedia.org]. That is, instead of securing the actual DNS records, it secures the communication between name servers and resolvers. With DNSSEC, you can get your DNS records for a totally untrustworthy server, and yet be able to prove if they are valid or not, but there isn't any form of encryption so there isn't

Trust is the same for DNSSEc, it's just that instead of using the root servers as a trust chain, you use a 3rd party that every domain owners had to pay for.

I hardly doubt many institutions will actually pay for signing their zones. o me it's more DNSSEC which is a hype and I'm under the impression many people pushing for it just don't know the implications (they just want to secure DNS).

DNSCurve is much easier to implement than DNSSEC and and also advantages in term of cryptography speed and increase of tr

Trust is the same for DNSSEc, it's just that instead of using the root servers as a trust chain, you use a 3rd party that every domain owners had to pay for.

DNSCurve does not require you to pay any third parties, it is like DNSSEC where you publish your own information. Both technologies are (or in the case of DNSCurve, will be) free.

DNSCurve is much easier to implement than DNSSEC and and also advantages in term of cryptography speed and increase of traffic.

DNSSEC has many years of actual deployment, not as wide spread as it needs to be, but it has been out there and tested.

Can you point me to a single implementation of DNSCurve? Can you even point me to a specification of what exactly it is? I've looked, and the best that I can tell, there aren't any. More over, it doesn't appe

DNSSEC has many years of actual deployment, not as wide spread as it needs to be, but it has been out there and tested.

Can you point me to a single implementation of DNSCurve? Can you even point me to a specification of what exactly it is? I've looked, and the best that I can tell, there aren't any. More over, it doesn't appear that DJB's website has been updated since he proposed DNSCurve last year.

From the namedroppers mailing list (IETF) there have been report of independently built client and server implementing DNSCurve. I alto trust Daniel J. Bernstein to update tinydns & dnscache as required if it gets adopted. Note that Microsft and Apple, who both have a good share of DNS servers out there, do not have a DNSSEC implementation yet.

DNSSEC rely on having a central "trusted" authority to sign all the dns keys. [...] that means that everyone will depend on a single authority for name resolutions

Uhm... No?

The root key signs the ".org" key, the.org key signs the "slashdot.org" key, etc. Unless the owner of the root key and the.org key is one and the same, you don't have the root controlling whether slashdot can get signed, and you don't have.org controlling whether.com can get signed (and what can get signed under.com).

DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.

Uhmm... so in DNSCurve you don't need to trust the root? Also, DNSCurve offers integrity of the communication, not integrity of the data. That means if I'm the MITM between yo

DNSSEC rely on having a central "trusted" authority to sign all the dns keys. [...] that means that everyone will depend on a single authority for name resolutions

Uhm... No?

The root key signs the ".org" key, the.org key signs the "slashdot.org" key, etc. Unless the owner of the root key and the.org key is one and the same, you don't have the root controlling whether slashdot can get signed, and you don't have.org controlling whether.com can get signed (and what can get signed under.com).

Go back to the specs. Every keys has to be signed by Network Solutions, and you must update your signatures every 3 month. If you have >100 domains to manage you sure can understand the pain:)

DNSCurve is a much better solution in that it offers a trust system without the need of a central authority. The key is embedded in the DNS name server (NS) hostnames which are always returned by the upper level name server.

Uhmm... so in DNSCurve you don't need to trust the root? Also, DNSCurve offers integrity of the communication, not integrity of the data. That means if I'm the MITM between you and your DNS resolver, assuming you don't connect to the resolver in a secure manner, I can still spoof all the DNS data I want to. That's not possible when the data is signed (or at least it appears to be equivalent to the problem of breaking the cryptography).

At least, this is how I understand it. I welcome any corrections:)

DNSCurve is a trust chain. You have to trust the root and every server in-between to guarantee integrity. Once implemented from the root to the final authoritative server the trust is complete. It doesn't require any modification to registrar interfaces to managing it though, as all you need is to change your NS ho

Every keys has to be signed by Network Solutions, and you must update your signatures every 3 month.

Well, actually it seems that I relied on confusing information - the truth is that the domain owner has to sign it, it just happens that Network Solutions will be the one signing all.com's and probably a bunch of other ones.

So "only" the people with.com domains will have to depend on the.com authority to sign their domains?And "only" the people with.org domains will have to depend on the.org authority?Is that really such a big improvement in practice compared to one root authority?

How much do you think they will charge to sign.com domains?

If the technology is really independent from all that "trusted authority signing" stuff, then it will necessarily also be vulnerable to MITM (and spoofing) attacks, unless the client has

Not quite. The "root key" will sign the root zone, and all the delegations for the TLDs (.com,.org,.ca,.uk,.gov, etc.)

The TLDs will then sign anything below them. So the.com key will sign the delegation to google.com, and the.org key will sign the delegation to slashdot.org.

It will be then be up to each organization to sign their own records, and possibly delegate any sub-domains.

Basically it's one large set up of PGP key-sign and webs of trust.

True. I've been a bit mislead... There's still a whole lot of domains that will be signed by network solutions though.

While DNSCurve sounds interesting (like a lot of Bernstein's stuff), besides his software, what uses it?

Actually his software does not even implement this yet (I guess he's looking to see if it gets traction from the rest of the world first). Besides, I read on an IETF list about people who independently wrote a client and server implementations. It is simpler to implement than DNSSEC in many aspects too.

I'd argue that one function of government is to fund and/or conduct research that wouldn't be economically viable in a for-profit organization. The space programs contributions to technology have already been well cataloged on slashdot and elsewhere.

Yes and those NASA-based advances only cost us 1 trillion dollars! What a bargain. Oh wait. No. Had those advances been developed privately, like velcro, they'd only cost 1/100th as much. The Market with its competitive natural selection and cost-cutting mechanism ("invisible hand") is naturally more efficient than politicians.

As for cars:

Well we saw what the government can produce. East Germany's government produced the 2-cycle Trabant, which you can smell coming a mile away, and that still used 50s

It's only worse at treating people that a sick AND poor. Rich sick people seem to have no complaints. Heck, the US seems to *import* rich sick people, which suggests the system is actually pretty good at caring for sick people, at least if they can afford it.

Honestly I think that it would have made more sense to leave space alone until tech reached a point where private enterprise could get there profitably but there was that whole international pissing contest.

On the upside it gave a generation an interest in science.

And there are sometimes things which while not profitable are still worth doing like certain kinds of research.

As a resident of the evergreen state, I'm stoked to see another one our intelligent, liberal, tech-friendly public servants appointed to a federal position:

(from the WP article in parent)

Locke would be the third resident of the Evergreen State named to the Obama administration, following deputy HUD secretary-nominee Ron Sims and Seattle City Police Chief Gil Kerlikowske who reportedly has been tapped to serve as "drug czar."

Locke is thoughtful, and having him in charge of the US's interest in IANA sounds li

And it supposed to be so by design, It makes sure that we jump back and forth and fly on every whim that everyone has.

That said the downside it is creates a Failure based culture where it is not what you do right that promotes you but what you do wrong that will get you fired, or prevented from promotion. So for many initiatives no one is willing to put there neck out and push the project. So the DNSSEC is on a list of things to do thats fine, you make sure you have other things on your list and wait until

The ISC DLV repository doesn't update the dlv.isc.org zone very often, about once a day at present (so I'm told), this further adds to slowing implementation of DNSSEC and registration of dnskeys to this repository.

The main thing that I'm not understanding is why the US Secretary of Commerce is responsible for specific technology decisions on the DNS.

Surely the political appointee to that post will not be qualified in any capacity to dictate the specifics about DNSSEC deployment.

Additionally, does the US Government still exert so much direct control over the DNS? I thought they divested their control to ICANN, so they could at least appear to not be thugs running the internet for their own benefit. However the ICANN