Seven People Who Hold the Keys to Worldwide Internet Security(theguardian.com)
theguardian.com
Seven People Who Hold the Keys to Worldwide Internet Security
http://www.theguardian.com/technology/2014/feb/28/seven-people-keys-worldwide-internet-security-web
15 comments
Yes the author is apparently writing about "Root DNSSEC KSK Ceremony 16"
http://data.iana.org/ksk-ceremony/16/KC16_Scripts.pdf
http://data.iana.org/ksk-ceremony/16/KC16_Scripts.pdf
> DNSSEC is a sideshow.
I recently had the occasion to attend a meeting of a body recommending standards for the Dutch government. (Serving) DNSSEC has been on their "use or explain"-list for well over a year (and the Netherlands apparently leads worldwide DNSSEC adoption.) At the meeting, the other attendees expressed their sincere regret that the DANE proposal, although a great idea, was still too immature.
As you probably know, DANE says that you "MUST" implement "trust this certificate, no matter what any CA says" over DNSSEC; combined with the fact that DNSSEC servers usually hold the signing keys online (NSEC3), implementing DANE is significantly less secure than just trusting the CA's. In fact, the Netherlands put quite a bit of effort into a government PKI infrastructure after our previous CA (DigiNotar) got pwned; it's not clear that requiring e.g. municipal system administrators to handle their own cryptographic keys is an improvement over what we have now.
Which is to say, don't discount well-meaning public servants; "given enough thrust, pigs can (temporarily) reach 6% of cruising altitude." </snark> [1,2]
[1] https://tools.ietf.org/html/rfc1925
[2] http://www.networkworld.com/news/2012/092412-ipv6-traffic-26...
I recently had the occasion to attend a meeting of a body recommending standards for the Dutch government. (Serving) DNSSEC has been on their "use or explain"-list for well over a year (and the Netherlands apparently leads worldwide DNSSEC adoption.) At the meeting, the other attendees expressed their sincere regret that the DANE proposal, although a great idea, was still too immature.
As you probably know, DANE says that you "MUST" implement "trust this certificate, no matter what any CA says" over DNSSEC; combined with the fact that DNSSEC servers usually hold the signing keys online (NSEC3), implementing DANE is significantly less secure than just trusting the CA's. In fact, the Netherlands put quite a bit of effort into a government PKI infrastructure after our previous CA (DigiNotar) got pwned; it's not clear that requiring e.g. municipal system administrators to handle their own cryptographic keys is an improvement over what we have now.
Which is to say, don't discount well-meaning public servants; "given enough thrust, pigs can (temporarily) reach 6% of cruising altitude." </snark> [1,2]
[1] https://tools.ietf.org/html/rfc1925
[2] http://www.networkworld.com/news/2012/092412-ipv6-traffic-26...
Doesn't it mean we can do CA-free authenticated HTTPS? That would make it useful for me.
No, it doesn't. It means that a different set of huge organizations, this time explicitly including world governments, will get added to the list of CA-equivalents.
Post-NSA-revelations, DNSSEC-based browser security is lunacy.
Post-NSA-revelations, DNSSEC-based browser security is lunacy.
[deleted]
How did this article manage to not use the byte sequence 'DNSSEC' or mention the fact that it's only deployed on a tiny % of domains under TLDs that support it?
Reports like this just add to public misconception.
Reports like this just add to public misconception.
This comment provided me with more information than the entire article. Would you care to add more details on what the key cards are and what their power is (the article seems to be stuck on "can they shut down the internet?")
This is really one of the worst kinds of stories. It's just not true, and not only is it not true, it purports to cover DNSSEC as a technology that people RELY or NEED, when in fact, DNSSEC adoption never gained traction, and actually decreases every single day.
Someone spun some crazy PR for this one.
Someone spun some crazy PR for this one.
in the interests of transparency: parent's business (OpenDNS) will have severe problems operating (replacing legitimate responses with spoofed ones) when DNSSEC is adopted.
That's actually not true, not even a little bit. We've covered this before. When the resolver issues a query, we can disable the DS bit and disable DNSSEC for our customers. Alternatively, we can extend our DNSCrypt client to do validation and rejection of malicious responses.
DNSSEC doesn't add security, nor does it prevent our business from operating to the fullest extent.
DNSSEC doesn't add security, nor does it prevent our business from operating to the fullest extent.
You're playing the long game. If OS's end up locally verifying DNS responses then you're out of business.
On the other hand, DNSCrypt is utterly useless and worthless. Wow, my ISP can't see that I'm looking up "www.example.com", oh... but my ISP can see that I am connecting to x.x.x.x on port 443 and sending "www.example.com" in the SSL handshake because of SNI. So now, both my ISP and OpenDNS (double the third parties) can see that I'm connecting to www.example.com, even if I'm using HTTPS. How exactly is this supposed to help my privacy?
DNSSEC and DNSCrypt both attempt do completely different things. DNSSEC is much better at doing what it is trying to do (even though it's far from perfect) than DNSCrypt.
On the other hand, DNSCrypt is utterly useless and worthless. Wow, my ISP can't see that I'm looking up "www.example.com", oh... but my ISP can see that I am connecting to x.x.x.x on port 443 and sending "www.example.com" in the SSL handshake because of SNI. So now, both my ISP and OpenDNS (double the third parties) can see that I'm connecting to www.example.com, even if I'm using HTTPS. How exactly is this supposed to help my privacy?
DNSSEC and DNSCrypt both attempt do completely different things. DNSSEC is much better at doing what it is trying to do (even though it's far from perfect) than DNSCrypt.
I am one of the biggest proponents of end-users running a full-blown resolver. I've been on the record on this point. Like the OP, it sounds like you really don't know what business we're in. Monetizing DNS with ads isn't our business, and it hasn't been for more than four years.
Sounds like you really don't know how to read. I didn't mention ads once.
Okay -- Maybe I jumped to your conclusion erroneously. How is my business impacted?
I think you're missing an "if" somewhere.
Ok, centralization leads to silly things like this.
Namecoin is but one of many ways to decentralize DNS while even while having one centralized registry.
Namecoin is but one of many ways to decentralize DNS while even while having one centralized registry.
"We peaked at 12."
Peaked. And that probably includes the sysadmin who was required to watch it.
Where are the articles on the new ridiculous TLD's?
A while back the IP address for the FTP copy of the root.zone changed.
And sure enough, the file is now full of crap like .buzz, .house and .kitchen
I cannot even read through the whole zone anymore. It's too long.
There are some gems in there though. And some fool paid $185,000+ for each one.
I have been running my own root for years and this is why.
Snip, snip. No more .buzz
Very easy to set up up your own custom root and to filter out the crap TLD's. But, like with the ceremony in this article, some folks think that ICANN has some sort of "authority" on how people use domain names.
Whole .com zone (=public information) fits on a USB stick.
And the HOSTS file remains as a failsafe, if you have to use someone else's resolver.
And most of the entries in the com.zone are garbage anyway: parked names with ads.
Imagine how many different domains the average user will visit in their lifetime. It is but a small fraction of all the names registered.
But let's pretend ICANN is relevant.
God help us if ICANN should cease to exist.
Peaked. And that probably includes the sysadmin who was required to watch it.
Where are the articles on the new ridiculous TLD's?
A while back the IP address for the FTP copy of the root.zone changed.
And sure enough, the file is now full of crap like .buzz, .house and .kitchen
I cannot even read through the whole zone anymore. It's too long.
There are some gems in there though. And some fool paid $185,000+ for each one.
I have been running my own root for years and this is why.
Snip, snip. No more .buzz
Very easy to set up up your own custom root and to filter out the crap TLD's. But, like with the ceremony in this article, some folks think that ICANN has some sort of "authority" on how people use domain names.
Whole .com zone (=public information) fits on a USB stick.
And the HOSTS file remains as a failsafe, if you have to use someone else's resolver.
And most of the entries in the com.zone are garbage anyway: parked names with ads.
Imagine how many different domains the average user will visit in their lifetime. It is but a small fraction of all the names registered.
But let's pretend ICANN is relevant.
God help us if ICANN should cease to exist.
How do you manage your own root?
1. Get copy of the file "root.zone" from ftp.internic.net
2. Load it into tinydns or nsd. I have a sed script that translates BIND format into tinydns format, but if you search you will find someone has written one in C.
3. Point your resolver at your root.
4. Create or delete TLD's at will, not to mention many other benefits.
Running your own DNS gives lots of control. Most malicious or deceptive practices that tarnish the internet rely on DNS. When you control your own, you can neutralize a very large percentage of it.
Redirecting .apple.com to your own httpd will show you just how bad this company has gotten.
You can also redirect ad servers like .doubleclick.net and voila, you will have free apps with NO ADS.
2. Load it into tinydns or nsd. I have a sed script that translates BIND format into tinydns format, but if you search you will find someone has written one in C.
3. Point your resolver at your root.
4. Create or delete TLD's at will, not to mention many other benefits.
Running your own DNS gives lots of control. Most malicious or deceptive practices that tarnish the internet rely on DNS. When you control your own, you can neutralize a very large percentage of it.
Redirecting .apple.com to your own httpd will show you just how bad this company has gotten.
You can also redirect ad servers like .doubleclick.net and voila, you will have free apps with NO ADS.
Redirecting .apple.com to your own httpd will show you just how bad this company has gotten.
Care to expand on that?
Care to expand on that?
I'm not going to rant about how Apple products make gratuitous network connections to remote computers for questionable reasons. Nor the requests that many AppStore apps send out over the open internet without telling you, or how poor Apple's forced software has gotten in general.
That's why I've presented you with the experiment.
If you think you might care about such things, try it yourself and draw your own conclusions.
If you use iOS, you might need this, just to get on your own home LAN:
/test/library/success.html <HTML><HEAD><TITLE>Success</TITLE></HEAD></HTML>
That's why I've presented you with the experiment.
If you think you might care about such things, try it yourself and draw your own conclusions.
If you use iOS, you might need this, just to get on your own home LAN:
/test/library/success.html <HTML><HEAD><TITLE>Success</TITLE></HEAD></HTML>
It's ICANN, not Icann. This article is overly sensational.
The Guardian's UK stylesheet calls for this treatment of acronyms that are pronounced as a word -- people say "Icann", not "Eye See Aye En En" -- which does seem odd but may be acceptable as a regionalism.
Some people make the following distinction: when pronounced as a word, it's an acronym. If it's not, then it's an initialism.
Some take the distinction further: only if it forms an actual word, like PATRIOT Act, is it an acronym. If it's pronounced but not a word, like NATO, it's an abbreviation.
I'm not a security expert, just an interested amateur.
Can someone explain how this step doesn't invalidate all of the hours of ceremony and procedure?
"Later Okubo will transmit the key on a secure channel to Verisign and this signed key will be made live across the internet."
Can someone explain how this step doesn't invalidate all of the hours of ceremony and procedure?
"Later Okubo will transmit the key on a secure channel to Verisign and this signed key will be made live across the internet."
Signing the key is the important part. Proving that the key was in fact created by the people it was supposed to be. (I think they key does have to be kept secure, which could be done by using a one time pad. Theoretically unbreakable.)
That's a public key/private key issue (I think!): the key he sends to Verisign will be the public key from the ceremony, not the private key.
If I'm mistaken about this, I hope the secure channel is very very very secure!
If I'm mistaken about this, I hope the secure channel is very very very secure!
Indeed! And I'm not even thinking about the communication channel as much as...Verisign. Not picking on them, but it's just a single, US based organization.
Doesn't revealing the identities of the key holders somewhat compromise the system? Ot at least make it more vulnerable?
I wish this story didn't read like a novel, and actually gave me the meat of the information more quickly. I feel like the way the author told the story diluted the importance of it.
I agree with you, it's way way way too long. And overly dramatic. I gave up reading pretty quickly.
However, judging by other comments here, I'm not sure there really was any "importance" to "dilute". It's probably just a way for apparatchiks to justify all-expense-paid vacations twice a year.
However, judging by other comments here, I'm not sure there really was any "importance" to "dilute". It's probably just a way for apparatchiks to justify all-expense-paid vacations twice a year.
Internet security is pwned by organisations powerful enough to hack into CAs or simply buy one and run them as a covert operation impersonating any site they want by issuing certificates trusted by all web browsers. Internet security broken by design of centralization.
Thus if you have IP A you will get fake certificate generated by government owned CA, if you have IP B you will get to the real site. If you are IP A you will get pwned by MITM attack malware the site will look genuine to the browser.
Thus if you have IP A you will get fake certificate generated by government owned CA, if you have IP B you will get to the real site. If you are IP A you will get pwned by MITM attack malware the site will look genuine to the browser.
Governments already directly own CAs.
The mitigation for the attack you outlined is that such attacks will be detected, and the CA will get blacklisted. That may not actually work in the real world.
The mitigation for the attack you outlined is that such attacks will be detected, and the CA will get blacklisted. That may not actually work in the real world.
In addition to everything else that's wrong with DNSSEC, using Shamir to share a digital signature key is a silly idea. Multisignature trust systems / threshold signatures provide the same functionality, but without having a single secret that has to live on one computer at a single time. While I know they did their due diligence to prevent the leak of the DNSSEC root key, it's a problem they could've easily avoided by using an incredibly boring design rather than a more "clever" one like Shamir. As things stand, there is actually one key that could completely destroy DNSSEC and require the thing be bootstrapped again from scratch.
"Once activated by the smartcards, this will produce a lengthy cryptographic code. If dropped, or even knocked too hard, the machine will self-destruct."
The first few paragraphs really overdramatize it. It makes it sound like the internet would completely cease to exist if something happened to the root DNS servers. It was so cheesy I just couldn't read anymore after that.
Oh, like scylla in "Prison Break?
Reminds me of http://www.youtube.com/watch?v=iDbyYGrswtg
I've written a bunch about DNSSEC on HN (and elsewhere) and won't preemptively repeat myself. You might consider just taking my word for this.