progbits 7 days ago | next |

This looks like routine key rotation. One year before it even starts being used and one more year before the old one gets revoked.

ggm 7 days ago | root | parent | next |

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.

progbits 6 days ago | root | parent |

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.

tptacek 7 days ago | root | parent | prev |

Technically this isn't a rotation; as I recall, the last attempted rotation was a fiasco?

sybercecurity 7 days ago | root | parent | next |

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

tptacek 6 days ago | root | parent |

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.

sybercecurity 6 days ago | root | parent | next |

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.

tptacek 6 days ago | root | parent |

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.

dc396 6 days ago | root | parent | prev |

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

teddyh 6 days ago | root | parent | prev |

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.

tptacek 6 days ago | root | parent |

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?

teddyh 6 days ago | root | parent |

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

tptacek 6 days ago | root | parent |

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)

dc396 6 days ago | root | parent |

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]

tptacek 6 days ago | root | parent |

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.

LeonM 7 days ago | prev | next |

Would have been nice if they would mention the key tag in the announcement. Its 38696 for those wondering.

ognyankulev 6 days ago | prev | next |

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

thayne 6 days ago | root | parent | prev |

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.

dc396 6 days ago | root | parent |

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.

rasengan 6 days ago | prev |

With a dedicated "key manager" on staff, this should be a much more secure process than it is currently.

dc396 6 days ago | root | parent |

There has been a dedicated key manager since before the first KSK roll. What about the current process isn't secure?