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

← Back to Stories (view on slashdot.org)

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

Posted by EditorDavid on Sunday October 1, 2017 @07:32AM from the losing-your-keys dept.

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.

42 comments

Min score:

Reason:

Sort:

KSK by Anonymous Coward · 2017-10-01 07:42 · Score: 0

WTF is KSK?
Yes too lazy to RTFA and all.
1. Re:KSK by cc1984_ · 2017-10-01 08:11 · Score: 4, Informative
  
  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.
2. Re:KSK by Antique+Geekmeister · 2017-10-01 08:43 · Score: 2
  
  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.
3. Re:KSK by MoarSauce123 · 2017-10-01 22:32 · Score: 1
  
  A new key after 7 years is too frequent? No offense, but sounds more like an excuse than a reason.
4. Re:KSK by Antique+Geekmeister · 2017-10-01 23:47 · Score: 1
  
  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.
5. Re:KSK by cc1984_ · 2017-10-02 00:15 · Score: 1
  
  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.
6. Re:KSK by Antique+Geekmeister · 2017-10-02 14:08 · Score: 1
  
  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.
7. Re:KSK by cc1984_ · 2017-10-02 20:31 · Score: 1
  
  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.
Blame DNS, not just the ISPs by Anonymous Coward · 2017-10-01 07:48 · Score: 0

When are we going to replace both with something that actually is peer to peer and can't be shut down? We need a "Citizens Band" for internet, but without the trucker music.
1. Re:Blame DNS, not just the ISPs by Anonymous Coward · 2017-10-01 13:36 · Score: 0
  
  That is the worst idea imaginable. Imagine all that computing power currently deployed on moderately pointless tasks like BTC being redirected to mine/crack naming services to MITM personal data. It gets even worse if you're thinking of a cooperative mesh network for IP delivery, where some bored dude just fires up a tcpdump and starts running some timing analysis on the encrypted traffic for funnies, or starts announcing random prefixes/service identifiers/however it chooses to work for fun.
  Oh so we need something or someone to arbitrate this stuff ... WAIT! Oh no, that's centralised again.
2. Re: Blame DNS, not just the ISPs by Anonymous Coward · 2017-10-01 15:24 · Score: 0
  
  APK is that you?
3. Re: Blame DNS, not just the ISPs by Zontar+The+Mindless · 2017-10-01 16:28 · Score: 1
  
  Probably not, since he's a big fan of C.W. McCall.
  
  --
  Il n'y a pas de Planet B.
Distributed is Slow by mentil · 2017-10-01 07:49 · Score: 2

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.
1. Re:Distributed is Slow by Anonymous Coward · 2017-10-01 08:01 · Score: 0
  
  Internet is already controlled by China and Russia. US abdicated its responsibility to lesser nations under Obama.
2. Re:Distributed is Slow by Anonymous Coward · 2017-10-01 09:55 · Score: 0
  
  Actually, no. The free world foresaw something like Trump, and started pressuring the forward-thinking people @usa to do something about it. They did, and so far it worked: ICANN isn't under control of any nation state, it is just about money.
3. Re:Distributed is Slow by JasonBoisclair · 2017-10-01 10:31 · Score: 1
  
  Just wait til launching a satellite is accessible to the middle-class hobbyist, the internet will be ours then!
4. Re:Distributed is Slow by Anonymous Coward · 2017-10-01 11:38 · Score: 1
  
  Uhm, no. ICANN't is still a California corporation, and various US judges have abused their power over US-based registries to seize domains owned by companies and persons otherwise well outside their jurisdiction. The US puts up a great show of "independence" but it simply isn't true.
  If the USG had been truly forward-thinking, they'd've not stepped in but had let Jon Postel have his way. This is a battle the community already lost a long time ago, whatever spin you're trying to put on it.
5. Re:Distributed is Slow by Anonymous Coward · 2017-10-01 13:46 · Score: 0
  
  That's 2 out of ~4 direct competitors to the USA, so how about also listing the "lesser nations"?
ICANN has nothing to do with the resolvers by Anonymous Coward · 2017-10-01 08:04 · Score: 0

ICANN has nothing to do with the broken widely-used resolver that failed to implement RFC5011 properly. The bleepingcomputer article is crap.
And any ISP basic IP services sysadmin worth something checked the KSKs when "head's up" emails were posted to every professional internet operations ML, so it is not a valid excuse, anyway.
In the future, it would be much better if the slashdot editors did their job and refused middlemen, accepting only submissions that link directly to the source (ICANN's report/advisory/notice in this case).
better way by bugs2squash · 2017-10-01 08:07 · Score: 1

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
1. Re:better way by Thanatiel · 2017-10-01 08:16 · Score: 3, Interesting
  
  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.
2. Re:better way by Anonymous Coward · 2017-10-01 10:13 · Score: 1
  
  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 to fix itself now that it will have 30 days to see the new KSK, if you updated it to get rid of the bug;
  3. you *still* have to use the latest version for newly deployed resolvers with the new KSK hardcoded, since they won't have enough time to observe the new key before they trust it. Alternatively, you manually configure the new KSK on them (when possible, most allow it but some don't).
  Almost everyone that kept their resolvers up-to-date had no issues.
Is anybody surprised of this? by Thanatiel · 2017-10-01 08:23 · Score: 2

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.
1. Re:Is anybody surprised of this? by Anonymous Coward · 2017-10-01 09:03 · Score: 0
  
  And it's exactly why this system won't work long term. It relies on everyone to update their keys on-time or suddenly: "Facebook is broken."
  If you automate the process, it becomes a primary target for abuse by the powers that be. Especially if it happens on a predictable reoccurring basis.
  TL;DR Trust is hard. Not saying I have a better solution, but this isn't it. Especially when ARP spoofing can bypass the entire system in an instant.
I know what a KSK is. by Anonymous Coward · 2017-10-01 08:32 · Score: 0

But not because you told me, because you didn't, ICANN. The ICANN page about the whole issue mentions "Key Signing Key" once, in a link that is part of the news archive section at the bottom of the page. This is how ICANN explains what's going on: "Rolling the KSK means generating a new cryptographic public and private key pair and distributing the new public component to parties who operate validating resolvers". No mention whatsoever that people have to do something. This looks like ICANN's failure to "distribute the new public component", not a failure by someone else to fetch it.
These people get paid handsomely. Literally every domain owner pays a registrar who pays a registry who pays ICANN. We really should expect a better job from ICANN.
1. Re:I know what a KSK is. by Anonymous Coward · 2017-10-01 09:59 · Score: 0
  
  Hmm, *every* IP basic services sysadmin worth his salary knows how DNSSEC works and what the KSK is. They're the ones that need to know it, not you.
  And we all got appropriate head's up on every network-operations-related mailing lists, everywhere (example: NANOG), and even oss-security got an warning from the ISC people (the ones who wrote the "bind" DNS resolver, one of, if not the most widely used DNS resolver in the world).
2. Re:I know what a KSK is. by viperidaenz · 2017-10-01 12:53 · Score: 1
  
  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.
3. Re:I know what a KSK is. by Anonymous Coward · 2017-10-01 20:18 · Score: 0
  
  Hey, wait! I'm one of those DNS server admins. Since when do I need to know what a KSK is in order to run a DNS server? My bind9 zone files have been running fine for decades with no changes needed (except maybe the addition of an AAAA record here or there).
  If this stuff is required maybe they should provide some way to test if my configuration is correct, or modify the DNS server software everyone uses (BIND) to spit out warnings if the configuration is wrong with respect to DNSSEC. Requiring 100% of admins to be competent is never going to happen.
  If someone set up a page called http://is-my-isp-dns-secure.example/ , had it say "Call your ISP immediately" when their configuration is wrong and published a link onto a few popular social media sites, I'm pretty sure that would get ISPs to get off their lazy asses and fix things pretty quickly.
This is why we have responsible disclosure by Anonymous Coward · 2017-10-01 09:13 · Score: 2, Interesting

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.
So? by thegarbz · 2017-10-01 09:13 · Score: 4, Informative

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.
1. Re:So? by Xest · 2017-10-01 18:50 · Score: 1
  
  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 around, let's face it, they wont, we'll still be waiting on them in a year's time.
2. Re:So? by thegarbz · 2017-10-01 21:50 · Score: 1
  
  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
Way to bury the lede! by thomst · 2017-10-01 10:34 · Score: 4, Informative

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.
1. Re:Way to bury the lede! by viperidaenz · 2017-10-01 12:56 · Score: 1
  
  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)
2. Re:Way to bury the lede! by 4im · 2017-10-02 00:38 · Score: 1
  
  "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 customers would be in deep trouble.
  Btw unbound used to have a different interpretation of the RFCs (for some more subtle points) than the bind guys, this made for a few... surprises. I hope it's gotten better since.
3. Re:Way to bury the lede! by Anonymous Coward · 2017-10-02 04:00 · Score: 0
  
  The safest way is to upgrade the software. Most vendors e.g. BIND have the new keys compiled in. If you don't do this rfc5011 will work until you fire up a new server with the old key after the old key has been removed.
  The article otherwise seems like clickbait. Easy to blame some 'Lazy ISPs' I guess instead of the process for the first ever key rollover. Not like anything bad would happen if you didn't do it right like the internet not working for most mortals.
Per #2 I don't (OpenDNS & local hosts file) by Anonymous Coward · 2017-10-01 10:54 · Score: 0

See subject: Via APK Hosts File Engine 9.0++ SR-7 32/64-bit https://www.google.com/search?hl=en&source=hp&biw=&bih=&q=%22APK+Hosts+File+Engine%22+and+%22start64%22&btnG=Google+Search&gbv=1/
Ads/script/malware rob speed/security/privacy/bandwidth.
Hosts add speed (via hardcodes/adblocks), security (vs. bad sites/malware/poisoned dns), reliability (vs. dns down), & anonymity (vs. dns logs/trackers).
Less power/cpu/ram + IO use vs. DNS/routers/addons/antivirus + less security bugs/complexity & faster vs. addons/routers/remote dns!
Avoids DNSChangers in routers/IP settings & dns redirect (99.999% of ISP DNS != patched vs. it) + DNS requestlog tracking & lighten DNS load & resolve faster from local system RAM!
* NATIVELY via a FASTER kernelmode IP stack & OpenDNS = redirect patched (99++% of ISP dns aren't).
APK
P.S. - Safe https://www.virustotal.com/en/file/e01211ca36aa02e923f20adee0a3c4f5d5187dc65bdf1c997b3da3c2b0745425/analysis/1433430542/
1. Re:Per #2 I don't (OpenDNS & local hosts file) by Anonymous Coward · 2017-10-01 16:36 · Score: 0
  
  Right, because your hosts file contains *every fucking domain on the fucking Internet*.
  So you can brag some more about how grand it is that your shitty app can peg all your cores.
  But in the world of APK, this is a GOOD thing!
Let's forget by Anonymous Coward · 2017-10-01 12:29 · Score: 0

... (ICANN) to delay the KSK Rollover ...

Translation: Shitty capitalism overrides government policy. Remind me again, how 'big government' causes all problems: I keep forgetting.
Wrong... apk by Anonymous Coward · 2017-10-02 01:17 · Score: 0

Never said I had every domain hardcoded in hosts. I keep 25 where I spend most time online resolving faster from local RAM & protecting me vs. DNS being 'down' OR kaminsky redirect poisoned (& keeps dns loads lighter too - bonus for their admins) + keeps me from being tracked on dns request logs (better anonymity).
* OpenDNS does the rest (rarely, like sub 4% of the time) & it IS patched vs. kaminsky redirect poisoning (unlike 99++% of ISP dns servers).
APK
P.S.=> See subject (that's "how you roll & what you do" vs. myself, constantly, you UNIDENTIFIABLE illiterate anonymous troll)... apk
Map? by coofercat · 2017-10-02 01:33 · Score: 1

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