[HN Gopher] Upcoming changes to the DNSSEC root trust anchor
___________________________________________________________________
Upcoming changes to the DNSSEC root trust anchor
Author : todsacerdoti
Score : 90 points
Date : 2024-11-06 09:02 UTC (13 hours ago)
(HTM) web link (lists.dns-oarc.net)
(TXT) w3m dump (lists.dns-oarc.net)
| progbits wrote:
| 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 wrote:
| 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 wrote:
| 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.
| ggm wrote:
| Yea, works. The intent wasn't to cause panic or concern of
| that I am sure.
| tptacek wrote:
| Technically this isn't a rotation; as I recall, the last
| attempted rotation was a fiasco?
| sybercecurity wrote:
| 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 wrote:
| 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.
| dc396 wrote:
| 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).
| sybercecurity wrote:
| 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 wrote:
| 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.
| teddyh wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| Would have been nice if they would mention the key tag in the
| announcement. Its 38696 for those wondering.
| ognyankulev wrote:
| 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 wrote:
| 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 wrote:
| 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.
| bewaretheirs wrote:
| 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.
| rasengan wrote:
| With a dedicated "key manager" on staff, this should be a much
| more secure process than it is currently.
| dc396 wrote:
| There has been a dedicated key manager since before the first
| KSK roll. What about the current process isn't secure?
___________________________________________________________________
(page generated 2024-11-06 23:01 UTC)