Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
Networking The Internet Security

ICANN Delays KSK Rollover Because of Lazy ISPs, Technical Faults (bleepingcomputer.com) 42

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.

This discussion has been archived. No new comments can be posted.

ICANN Delays KSK Rollover Because of Lazy ISPs, Technical Faults

Comments Filter:
  • by mentil ( 1748130 ) on Sunday October 01, 2017 @02:49PM (#55288659)

    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

    • Just wait til launching a satellite is accessible to the middle-class hobbyist, the internet will be ours then!
  • 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

    • Re:better way (Score:4, Interesting)

      by Thanatiel ( 445743 ) on Sunday October 01, 2017 @03:16PM (#55288761)

      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)

    • by Anonymous Coward

      Well, there's RFC5011, which updates the KSKs automatically *as long as the server sees the new key for a month*. But:

      1. some resolvers don't implement it for whatever reasons, but those hardcode the KSK so if you updated them recently, you got the new KSK;

      2. one widely-used resolver had a bug and did not trust the new KSK, and this one would actually need a manual override (or purge and reinstall) to unbreak, even after being updated (due to stale data that overrides the built-in KSKs). But this is going

  • by Thanatiel ( 445743 ) on Sunday October 01, 2017 @03:23PM (#55288785)

    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.

    • by Anonymous Coward

      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 unaccepta

  • So? (Score:5, Informative)

    by thegarbz ( 1787294 ) on Sunday October 01, 2017 @04:13PM (#55288961)

    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.

    • by Xest ( 935314 )

      Agreed, it seems like the obvious solution is to just do it. 60 million people without DNS is hardly a big deal compared to 5 billion facing potentially compromised DNS.

      Just do it, and watch how quickly the ISPs sort it out when their phone lines are hammered because people's internet connections are "down". Lessons will be learned, and those ISPs will be on it next time around.

      I can't think of any worse a solution than simply delaying in the hope that those ISPs will get their arses into gear next time aro

      • I can't think of any worse a solution than simply delaying in the hope that those ISPs will get their arses into gear next time around, let's face it, they wont, we'll still be waiting on them in a year's time.

        I can think of something worse: Technical workarounds. Stay tuned for DNSSEC-NAT

  • by thomst ( 1640045 ) on Sunday October 01, 2017 @05:34PM (#55289271) Homepage

    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.)

    • It explains why they're delaying the rollover instead of doing it regardless of impact to the "lazy ISP's".

      The headline does say "Lazy ISPs, Technical Faults"

      (Added emphasis mine, of course)

    • by 4im ( 181450 )

      "Some ISPs opted to use this software, which apparently had some bugs and failed to download and install the new KSK,"

      I used to work DNS at my ISP, several years ago. Back then, I did the first setup of the DNS resolvers using DNSSEC, testing with both bind and unbound. Neither of those, back then anyway, would automatically handle KSK change, the key resided in a plain file in the server configuration. I sure hope the people that took up DNS there after I left upgraded the server software used, and are keeping an eye on the subject.

      I know where to get DNS resolving in case the ISPs servers cause problems... other customer

  • 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 ;-)

It has just been discovered that research causes cancer in rats.

Working...