This looks like routine key rotation. One year before it even starts being used and one more year before the old one gets revoked.
Yes, but the routine here is still (in decades terms) new. So, declaring things you do which are "normal" is part & parcel of making this experience as good as it can be.
"nothing to see here, move along" is not a good posture. "in case you're interested" is begging a question: should I be? Simply declaring/reminding, to my mind is the best position.
As normal, we're doing the normal thing. this is the gating time. Read more here.
Sorry if it came across that way, I wasn't trying to be dismissive. However the title "upcoming changes" made me think this was some unexpected / breaking change.
I think something like "Root trust anchor rotation: you have 1 (or 2) year to update" would be more accurate.
Yea, works. The intent wasn't to cause panic or concern of that I am sure.
Technically this isn't a rotation; as I recall, the last attempted rotation was a fiasco?
It was delayed, but was successful. The available metrics at the time showed that many validators did not pick up the new key, or did not store it in stable memory so every time a new VM/container/whatever started up, it had the old key. Once those were fixed, the rollover completed.
That's the problem with doing maintenance on infrastructure used by every host on the Internet. Though efforts to replace DNS with a more distributed model has never succeeded (yet).
Yeah I'm not making a point about DNSSEC or its alternatives so much as just pointing out that the last rotation was a big story, and that this is not a big story.
I guess I misinterpreted it - sorry. It must say something that it isn't a big announcement anymore: either it has gotten to the point where people expect it (good operations), or people are expecting DNSSEC to go away (bad for DNSSEC).
Still, with the reliance on the DNS for things, it would be nice to have it be secure. Or a DNS 2.0 that has solves a lot of the current issues with the protocol, but DNS has proven resilient and adaptable enough to continue working since RFC 1023 and 1035.
I disagree on securing the DNS (and about how we should go about it, if we must) but in any case, have no criticism about today's announcement.
It was a big story because (a) it was the first time it was attempted; and (b) there were concerns that older software would need manual intervention to update the key, thus there was a need to make it into a big story to ensure appropriate folks would update the trust anchor (this turned out to be a non-issue).
It is the first step of a rotation. Rotating the key is the whole point of doing this. There was no “fiasco”. I really wish you’d stop trying to throw shade on DNSSEC whenever you can.
That's not DNSSEC shade; it was a big story at the time. They eventually managed to rotate the keys but had to delay it, I think by more than a year?
It was reported because it was technically interesting, not because anything actually failed. They anticipated something might happen, monitored for it, found something did indeed happen, and made appropriate adjustments and fixes. Then the plan moved ahead, and the rollover happened without any further issue.
Your parent comment has been downvoted and flagged. Take the L instead of doubling down on your strange obsession on calling everything related to DNSSEC a “failure” and “fiasco”.
I don't know why you're commenting on the voting here. I don't care and neither should you. I'm saying: the observation I made wasn't "shade". It is in fact a useful thing to know about DNSSEC that the last attempted key rotation was operationally complicated and disrupted to the point where it was delayed for over a year† (relevant, given that rotation of these keys exists as a response to potential compromise in them!), and that the announcement today is not the same thing as the rotation itself.
Obviously, I'm not a DNSSEC supporter, but I think what's happening here is that you've read all our previous discussions into a relatively innocuous comment.
At any rate:
Please don't comment about the voting on comments. It never does any good, and it makes boring reading.
https://news.ycombinator.com/newsguidelines.html
† (iirc)
I see, so you're calling prudent caution when doing something that can impact a non-trivial portion of the entire Internet a "fiasco" and saying it isn't "shade". Okey dokey.
FWIW, you recall incorrectly. The decision to delay the key roll was made to understand some unexpected data detected when some preliminary actions related to the roll were taken. After analysis, it was determine the signals were the result of some flawed assumptions about resolver behaviors and innocuous. I suppose ICANN could've moved forward blindly, but then I guess you'd criticize them for taking unwarranted risks.
[edit: a word]
I honestly don't care what valence you're assigning to the word "fiasco" --- they planned a rotation and scotched it twice, as I recall, you can use whatever word you like. Here, the point was that wasn't happening. I'm broadly critical of DNSSEC, but haven't criticized anything about today's announcement.
Would have been nice if they would mention the key tag in the announcement. Its 38696 for those wondering.
I was hoping it's NIST ECDSA P-256 (algo 13) for smaller DNS packets, instead of what they did with continuing with RSA 2048 (algo 8).
Most of the big TLDs have already converted to algo 13 -- .org is still lingering on algo 8, but .com, .net, .edu, .gov have all converted, so a lot of the DNS traffic is using smaller signatures already.
Changing the algorithm for the root is being studied - see for instance https://lists.icann.org/hyperkitty/list/ksk-rollover@icann.o... ; I wouldn't be surprised to see an algo change as part of the next root key rollover.
My guess is they did that to be compatible with FIPS 140-2.
FIPS 140-3 allows ECDSA, but isn't widely deployed yet (among sites required to comply), so using ECDSA would probably cause issues for government organizations that need to use FIPS and DNSSEC.
Nah. Changing algorithms is a bigger deal than rolling the key. They want the make sure rolling the key is a non-event before taking on changing algs. Changing the algorithm is being discussed however.
With a dedicated "key manager" on staff, this should be a much more secure process than it is currently.
There has been a dedicated key manager since before the first KSK roll. What about the current process isn't secure?