[Yeti DNS Discuss] Notes from Yeti 2nd Virtual meeting
shane at biigroup.cn
Tue Mar 29 10:01:12 UTC 2016
On 2016-03-25 20:44:43-0700 (Friday)
David Conrad <drc at virtualized.org> wrote:
> > Shane mentioned the IANA KSK roll status:
> > http://yeti-dns.org/resource/2016-03-24/2016-03-24-icann-ksk-roll.pdf <http://yeti-dns.org/resource/2016-03-24/2016-03-24-icann-ksk-roll.pdf>
> Um. From that presentation:
> "Root KSK DPS: roll every 5 years – Signed 2010-07-15 (> 5.5 years ago... oops!)"
> The actual ICANN KSK DPS policy statement (the first sentence of section 6.5 of https://www.iana.org/dnssec/icann-dps.txt) says:
> "Each RZ KSK will be scheduled to be rolled over through a key
> ceremony as required, or after 5 years of operation."
> (emphasis added). It does NOT say "roll every 5 years".
I don't know if you were part of writing the DPS, but even if you
weren't you have a lot more insight into it than I do. Also, IANAL and
ICANN is about 90% lawyers, and presumably these lawyers have given
their legal opinion - so I'm sure that in a court your point is correct.
Still... the interpretation of this statement to mean that the RZ KSK
was to be rolled NO EARLIER THAN 5 years seems a bit odd to me. If this
was the case, the "5 years" could just have been left out and the
statement left as:
"Each RZ KSK will be scheduled to be rolled over through a key
ceremony as required or otherwise deemed prudent."
That doesn't really seem to be the intent. To me it seems pretty clear
that every 5 years the RZ KSK was meant to be rolled.
Of course the exact timelines and dates do not matter. The crypto is
still secure, and the processes still work. I just find it a bit ironic
that there is absolute dedication to the ZSK schedule when the KSK
schedule is so flexible. :)
> We're in the process of developing the necessary plans and processes
> to attempt to safely and responsibly roll the KSK _after_ 5 years as
> the DPS requires. As every validating resolver on the planet will
> need to update their trust anchor in response to this roll, you can
> probably imagine that this is a non-trivial exercise when you're
> talking about not disrupting the production Internet (or at least 25%
> or so of that Internet that is currently validating responses) upon
> which trillions of dollars of GDP depend.
Sure, we're kind of in a pickle now. I guess people calling for the
"roll early, roll often" probably feel pretty smug, since that
would have prevented this situation. (I wasn't one of them, although I
also didn't argue against this.)
Even the work at the IETF to get better metrics about validation don't
really solve the problem - they just let us make an informed decision
about how much of the Internet we're going to have to break when we
roll the NEXT time.
The main casualty if things go pear-shaped would be DNSSEC itself, as
almost everyone would likely disable validation just at the time when
DNSSEC was gaining more and more traction. :(
> We anticipate providing more details on the plans for the KSK roll in
> the near future.
Great, looking forward to it!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: OpenPGP digital signature
More information about the discuss