Kaminsky calls for DNSSEC deployment ARLINGTON, VA. -- Dan Kaminsky's second act has begun: Pushing the adoption of the DNSSEC security standard for the domain-name system. So many security frameworks — from password resets via e-mail to SSL certificates — rely on DNS in some way that the protocol has to be secured for Internet security to work, Kaminsky told …
Please tell me that you're being sarcastic, and that you're not *THAT* stupid. The US government has a very long track record of doing whatever it wants, regardless of legality and regardless of how it affects other countries. Here are just a few examples:
1. Changing the US' daylight savings time (which isn't even permanent; they reserved the right to change it back if they feel like it).
2. The illegal NSA wiretaps.
3. The US government refusing Freedom Of Information Act requests requesting the truth about the JFK assassination which occurred over 45 years ago.
4. The UIGEA law, the US law banning online gambling, which was ruled illegal by the WTO. The US basically said "screw you, we'll do whatever the hell we want".
5. The "agreements" between the US and EU regarding airline passenger (PNR) data. The US has never, and will never, agree to the same data protections that the EU requires on such data, but the EU has agreed to hand the data to the US anyway (thus violating EU law) because otherwise EU citizens would not be able to fly to the US.
6. Guantanamo Bay, whose sole purpose is to imprison and torture people without having to follow those pesky US laws, not to mention those pesky international laws agreed to at the Geneva conventions.
As for your comment about this being no different than the International Standards which are located in France -- how often are those original standards used to verify data? DNS servers are queried millions of times every day, and a change could result in anything from an invisible man-in-the-middle attack (because if your system gets a rogue DNS answer, it'll think it's connected to the correct site, and you won't know any different) to literally sectioning off any part of the Internet the government wants to censor. Think about it as Big Brother to the Great Firewall of China. By giving the US government complete control over the root server, you're effectively giving the US the ability to censor the Internet for the world. But hey, that's OK, because I'm sure nobody here is cynical enough to believe the US government might ever do anything unsavory or questionable.
Lastly, given the US government's undeniable lack of computer security, do we really want THEM to be the ones in charge of protecting the security of the entire Internet?
I think its quite different. It is one thing to adopt a standard, its quite another to put someone else in control of the your implementation.
Can you really see Iran and North Korea putting themselves in the position whereby the US can kill their DNS by revoking their certificate?
I thought not.
Certificates destroy the distributed nature of the internet. You are trading freedom for security. I'm pretty sure people have commented on that in the past.
Most firewalls and client DNS systems can do quite a bit in terms of making DNS stateful which mitigates many attacks. Calling for DNSSEC when the problem is unpatched systems is rather missing the point.
One internet for the United States. One internet for the rest of the world. Or at least two sets of root servers. Yes, the internet would diverge as the one in the US and the one France/The Hague applied different levels of Censorship.
Really though, I don't want Americans or American values controling my life, and I am certain the rest of the world doesn't either. That said, I don't trust the Aussies the Kiwis or the Brits at this either. Canada, A Scandanavian Country, Germany or France please. While they certainly have thier problems, they seem far more trustworthy than the alternatives. Better yet, why not get an international (gasp, horror, cross country co-operation!) organisation to administer it? Something so easily bought as the ISO. IEEE perhaps? Some arm of the UN?
One thing's for sure, I trust no organisation or government that puts the desires of a corporation over the needs of the people.
Hey Chris C "Lastly, given the US government's undeniable lack of computer security, do we really want THEM to be the ones in charge of protecting the security of the entire Internet?"
Haven't they been doing wonders already turning our banking system into a giant welfare program? Im not sure at this point what's worse. All the corporate thugs controlling the internet (as they do, arin,icann etc.... they all operate from money in toliet stalls) or our government which we could sum up their ability in one word."Amtrak" What a raging success that government ran program has been.
I say 50/50.
If DNSSEC requires a single root, then is it not broken by design. It sounds like the system has a single point of failure. Could each country not maintain its own roots, securing the domains for said country.
It sounds like a typical IETF plan, poorly thought out, full of implementation issues and general pain.
Currently, recursive DNS servers need to be kept up to date with the addresses of the root servers. This changes rarely, maybe once a year.
Why not allow the organisation looking after each TLD to sign their zone then distribute updated keys once a year?
Ok, greater administrative overhead and not 'correct', but China, Iran, Russia et al can rest assured that their DNS is safe from those in the US.
Perhaps I'm missing something.
If you don't like the idea of the US managing the top of your chain of trust in domain names there is little to prevent you and a few others with like minds operating another root server which contains a certificate you do trust signing the TLD DNS servers you consider to represent the names in question. Then configure your DNS clients and servers to trust your root server instead of the one operated by the US. You'll need pretty good bandwidth and resilience though, but the budget to do this isn't beyond what a well organised activist group could raise, and could grow with demand for an alternate DNS root.
Also if you don't want to go that far then decide which TLDs you do trust and configure your DNSSEC trust anchors there which override any changes made in the US government root server, and trust the US root server for other TLDs.
Setting up an alternate DNS infrastructure isn't impossible, given that the schools have done this to filter adult content based on domain name, see:
http://www.opendns.com/ .
OpenDNS do this based upon their customers' and users' agenda, so there is nothing to prevent those who don't trust the US to sign the root zone to setup and configure a root zone they do trust. But learning and paying for and operating the technology will give you a lot more traction here than idly arguing the politics if you are not willing to put your money and time where your mouth is.
Each TLD is signed separately with DNSSEC. The way you can tell that the TLD signature is valid is by looking up the key associated with it one level higher up. The same method is used to let domain owners create domains without needing to get the TLD to resign its zone file.
The question here is who signs the root zone? By necessity, the key used to sign the root is implicitly trusted by DNSSEC resolvers. That effectively gives then the ability to choose which key is authoritative for each TLD, which some people consider a problem (above their existing ability to redelegate a TLD).
I've not read all of the DNSSEC RFCs, but the way this works for HTTPS is that your system (by nature of installing the web browser) has a list of trusted root publickeys, and each key lookup is a chain of signatures which must end up being signed by one of the configured roots.
RFC 4033 similarly implies that you can store a list of "trusted root keys", i.e. a country such as China could easily add extra keys, or a company can add it's own root key for signing internal web sites instead of paying Verisign for internal systems.
As such, the article says "in the simplest case, a single root" but a non-single solution could also be possible. It depends on how keen people really are to implement DNSSEC at all.
A possibly bigger political question is what the companies who sell HTTPS certificates will make of this, given that DNNSEC may overlap or reduce some of the need for HTTPs, and the current market for HTTPS certificates makes a bunch of money. This therefore raises the question of who would get the money for all of the DNSSEC certificates if there's a single root signer.
The DoC has operated the root zone forever, and the only alternative is worse (IANA itself), so bitch about it *now* isn't likely to achieve much unless a viable alternative is mooted.
But, that has little to do with DNSSEC, other than cementing authority that's already pretty firmly held.
The solution is to distribute the public keys of the TLDs alongside the root NS hints. That _file_ can be signed (e.g., by PGP), which the OS/DNS resolver vendors (who are the ones who pick up the root hints file and distribute it to their users) can verify that it was generated and signed by somebody that they—on behalf of their users—deem trustworthy.
The benefit of this over simply signing the root zone is that it's not any more complicated than the key-distribution mechanism that'll be required for the root zone signing key anyway, and it makes the signature of the root zone irrelevant for most purposes: because the TLD signatures can be verified without referencing the root, it can be signed by the US, or IANA, or nobody at all, and it doesn't make one bit of difference. If the world has a falling-out with the DoC (or IANA), it's a matter for the world's Internet users (via the resolver distributors) to decide who the new trustworthy source of TLD keys is. They could even form a web of trust whereby each vendor picks a TLD, verifies its key in person, and distributes it to the others; no single-point root key distribution required.
Of course, the danger with this is that it would demonstrate how irrelevant IANA really is.
"A possibly bigger political question is what the companies who sell HTTPS certificates will make of this, given that DNNSEC may overlap or reduce some of the need for HTTPs, and the current market for HTTPS certificates makes a bunch of money. This therefore raises the question of who would get the money for all of the DNSSEC certificates if there's a single root signer."
You normally pay annually to have a name in .org or .com or every 2 years to have a name in .co.uk . With DNSSEC the domain registrar will have to provide cyrypto certification services along with domain registration. So I expect the fee for both services will be combined and will go to the registrar, with a share going to the maintainer of the next level up as currently occurs. By killing 2 birds with one stone, this neatly deals with a significant cost in maintaining a cryptography chain of trust, in the sense that keys need to have expiry dates and rollover if revocation lists are not to grow without limit and become unusable over time.
Root zone server operation as I understand this is a collective and not a dictatorship see: http://www.isoc.org/briefings/019/ .
There seems little preventing this collective from deciding to accept another provider as the compiler of the root zone file, which is a tiny set of data that doesn't have to change very often. I imagine that some of the costs of domain registration will go to covering the costs of the organisations which operate the root zone servers and the much smaller cost of compiling the root zone itself. As I understand these, the politics associated with the maintenance of the two letter country code TLDs ( e.g. .uk ) are more defensible than those associated with the global three letter TLD codes (e.g. .com or .org).
> You normally pay annually to have a name in .org or .com or every 2 years to have a name in
> .co.uk . With DNSSEC the domain registrar will have to provide cyrypto certification services
> along with domain registration.
Yes, I know about the cost or registering a domain name. My point if that the registrars charge maybe $5-10 per year for the domain name but often north of $100 for a SSL certificate. If the $5-10 now includes a DNSSEC key (as it should) then the need for the $100+ certificate may decrease. Which would be good news for end users although not necessarily for the certificate providers.
Fast, effective, costless solution. Of course there's no money in it for the security guys, so they push DNSSEC instead... administered by the US gov. Yeah right. How long before half the internet is Arkansased? (China, Iran, "adult" sites, non-christian-values abiding domains, gambling sites, domains featuring "inapropriate" language, anyone who doesn't spy on users -or who does but doesn't give the info to the CIA, ...)
Not sure I follow your logic here. Signing DNS and SSL certificates are two completely different things, and serve completely different purposes.
DNSSEC confirms that the IP address returned when you make a DNS request is the correct one.
SSL confirms that the website you reach is the real one, eg the https:\\secure.foo.com you see really does belong to Foo Corporation, and not Mr B H Hacker who's setup the site on his server and tricked your computer to go to him instead of the real one. It provides authenticity by ensuring that if you want to purchase an SSL certificate for Foo Ltd, you can prove that you really are Foo Ltd (there's quite a few checks done, especially if you're a Ltd or PLC company, hense their justification for the high prices). And finally, and perhaps most importantly, it allows you and the server your connecting to to establish a secure tunnel down which all the communications are sent, thus protecting you from anyone sniffing your connection.
What SSL doesn't do is care about what IP address the site is on. As long as you have the certificate information you can install it on any server at any address. So the two don't cross over at all, to my mind they compliment each other, improving the overall security for viewing normal websites, and improving yet futher the security of secure websites.
"Signing DNS and SSL certificates are two completely different things, and serve completely different purposes."
At first sight yes this seems to be the case. But I think DNSSEC goes further than what it claimed to do in the first instance. There is clearly an overlap in the sense that both provide assurances concerning ownership of a domain name. DNSSEC extends to providing a more complete PKI coverning applications in the sense that the difference between rich@example.com and rich.example.com is one of syntax and not semantics.
Also As I understand this RFC4398
http://tools.ietf.org/html/rfc4398 "Storing Certificates in the Domain Name System (DNS)"
concerns using DNS for storing, authenticating and providing certificates for the purpose of applications other than DNS.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
