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.
Doing that is easy. Both keys need to sign records for a while.
A new KSK is published and as such signed in the zone along with the previous KSK.
This new KSK can automatically accepted as valid by resolvers and when, days later, the old KSK is removed, only the new KSK signature remains (or more accurately: is remade, as it covers all DNSKEY records)
DNSSEC is not that complicated (if you ignore the convoluted NSEC3 chains)
Irrelevant news and morons using moderation to mod down what they disagree on. 2018 resolution: so long.
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.