Slashdot Mirror
ICANN Delays KSK Rollover Because of Lazy ISPs, Technical Faults (bleepingcomputer.com)
ICANN had planned to change the master key used to sign secure Domain Name System records next week for the first time in history. But now an anonymous reader writes:Inattentive ISPs and technical faults have led the Internet Corporation for Assigned Names and Numbers (ICANN) to delay the KSK Rollover for next year. ICANN was supposed to remove the root encryption KSK key from core DNS servers on October 11 and allow a new one to take effect. The key is used for the DNSSEC protocol.
According to ICANN, between 6% to 8% of ISPs did not install the new KSK key to replace the one issued in 2010. The organization says that if it had gone forward with the original KSK Rollover plan, over 60 million Internet users would have been unable to make DNS requests. For the vast majority, ICANN blames lazy ISPs, which failed to update their existing keys. ICANN also believes that many ISPs may not be aware they had not installed the latest KSK. ICANN also distributed software to automatically pull down and install the new KSK. Some ISPs opted to use this software, which apparently had some bugs and failed to download and install the new KSK, in some situations.
Because of this, ICANN announced this week it would delay the KSK Rollover final step — of removing and revoking the original KSK key -- to the first quarter of 2018. ICANN has not decided yet on a precise date.
According to ICANN, between 6% to 8% of ISPs did not install the new KSK key to replace the one issued in 2010. The organization says that if it had gone forward with the original KSK Rollover plan, over 60 million Internet users would have been unable to make DNS requests. For the vast majority, ICANN blames lazy ISPs, which failed to update their existing keys. ICANN also believes that many ISPs may not be aware they had not installed the latest KSK. ICANN also distributed software to automatically pull down and install the new KSK. Some ISPs opted to use this software, which apparently had some bugs and failed to download and install the new KSK, in some situations.
Because of this, ICANN announced this week it would delay the KSK Rollover final step — of removing and revoking the original KSK key -- to the first quarter of 2018. ICANN has not decided yet on a precise date.
If the Internet were centrally controlled by a dictatorship, then this democracy-preserving security feature would've been rolled out by now! That's why ICANN should relinquish control to China and Russia. /s
Corruption is convincing someone that the selfless ideal is the same as their selfish ideal.
we roll over keys, certificates and passwords at work too, it's a chore every time. There must be a better way to do this, ideally there could be a grace period where old and new keys are in force and users get progressively worse nag messages about the impending demise of the old key/whatever.
If the protocol doesn't support messaging then maybe it should degrade, start off with a 1ms delay and then ramp up exponentially as the deadline nears
Nullius in verba
Key Signing Key. DNSSEC is built on public key cryptography. You sign your zone with a Zone Signing Key ZSK, then sign the ZSK with your KSK, the public key part of which is available in your parent zone. The theory goes that you can roll over your ZSK frequently (and you should) without involving your parent zone.
For as long as I remember, most companies only care about security a bit after some critical issue happen. Then they act as it was their chief concern.
Irrelevant news and morons using moderation to mod down what they disagree on. 2018 resolution: so long.
As some of us can point out, updating root keys _cannot_ occur on a frequent basis. Lazy ISP's or not frequent mandated updates require customer collaboration. They also require the _designers_ of DNS capable applicances to be forward thinking enough to provide effective pathways for such updates.
This is why we have responsible disclosure in security.
In the old days, many companies had major issues with publishing security fixes quickly until they were forced to because they didn't want to spend the time and resources to fix the issue.
As a result, security researchers started releasing details of the vulnerabilities after warning the company and giving them some time to fix the problem. This forced the companies to change their behaviour.
The end result is that it is now completely socially unacceptable for a company not to produce a security fix when it has been given a reasonable amount of time to produce the fix.
The same mindset needs to happen here. ICANN needs to go ahead with the KSK rollover and when things break, they tell people that the companies were warned and did nothing about it.
The companies then get to explain to their customers why they did nothing about this.
This attitude has dramatically improved computer security over the years and it's the same attitude which needs to be applied here.
Possible outcomes of moving forward:
1. 60m people call their lazy ISPs and the ISPs get their shit in gear / sued for causing an outage due to negligence.
2. 60m people stop relying on shitty ISP's DNS servers.
Accepting tyranny of minority is not the right way to handle internet infrastructure.
The key capture here comes down to this pair of sentences (especially the second one):
ICANN also distributed software to automatically pull down and install the new KSK. Some ISPs opted to use this software, which apparently had some bugs and failed to download and install the new KSK, in some situations.
Instead of "lazy ISPs", as the headline misleadingly states, it sure appears to me that the party actually responsible for the failure of the KSK update rollout is ICANN itself.
Or is there some aspect of, "Some ISPs opted to use this software, which apparently had some bugs and failed to download and install the new KSK," that I'm misapprehending ... ?
(Added emphasis mine, of course.)
Check out my novel.
You shouldn't be maintaining a DNS server if you don't know what a KSK is.
If you're not maintaining a DNS server, you don't need to know what a KSK is.
Probably not, since he's a big fan of C.W. McCall.
Il n'y a pas de Planet B.
A new key after 7 years is too frequent? No offense, but sounds more like an excuse than a reason.
I see your point. However, I was responding to this:
> The theory goes that you can roll over your ZSK frequently (and you should) without involving your parent zone.
The idea that the ZSK chain of authentication should be frequently rolled over is simply not going to happen.
The idea that the ZSK chain of authentication should be frequently rolled over is simply not going to happen.
I don't understand. It's the KSK that has a slow rollover which is what is being discussed in this article, and the ZSK with the faster rollover. I never said the KSK should never be changed, but at the same time, I didn't say it should be frequent.
I've love to see a 'heat map' of the world with the location (to the nearest country would do) for these lazy ISPs and issues. I'll bet it'll either look exactly as you'd expect, or the exact opposite of what you'd expect ;-)
My point was responding to your post.
> The theory goes that you can roll over your ZSK frequently
I'm afraid this is not going to happen.
I'm afraid this is not going to happen.
That's why I said "in theory" :)
Reminds me of a joke I heard:
Q: What's the difference between theory and practice?
A: In theory they're the same, but in practice they're different.