[Yeti DNS Discuss] Notes from Yeti 2nd Virtual meeting

David Conrad drc at virtualized.org
Tue Mar 29 14:39:52 UTC 2016


Shane,

On Mar 29, 2016, at 3:01 AM, Shane Kerr <shane at biigroup.cn> wrote:
> I don't know if you were part of writing the DPS,

I had a minor role, but was involved (being manager/budget owner of the team that wrote it).

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

And yet, that wasn't the wording despite the fact that the authors of the DPS were all quite competent in English and were very well aware of the issues. One might wonder why that is. A hint: when the DPS was being written (circa 2009), how many validating resolvers supported RFC 5011? A second hint: when ICANN held a vendor workshop at the LA meeting in 2014, how many validating resolver then supported 5011 and did so correctly?

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

I suspect those folks will feel smug regardless. However, an alternative outcome of folks saying "when you're done fooling around with the root key, let us know and we'll think about turning on DNSSEC" might have occurred and that was a real concern at the time. There is also the reality that every time you touch the KSK you increase the risk of catastrophic failure/compromise and given RFC 5011 rollover requires a valid key and that _RFC 5011 does not help in the event of said catastrophic failure/compromise_, the idea of "roll early, roll often" for an infrastructure upon which trillions of USD depends may given one pause (and yes, we do what we can to minimize the chance of catastrophic failure/compromise, but that risk will always be non-zero).  One might look at the frequency at which the root certificates of top-level X.509 CAs are rolled for an indication of how these sorts of things are dealt with in other security realms.

In my view, the decision to defer the first roll until _after_ 5 years was a reasonable compromise to allow for deployment of software that supported automated rolling, encourage (or at least not discourage) deployment of DNSSEC (which, as you might recall, we were in a rush to do due to the publication of the Kaminsky attack in late 2008), and minimize the risks associated with mucking about with the new key management infrastructure that had just been deployed.  Others have a different view, which is fine. It's mostly water under the bridge now.

I hope this clarifies.

Regards,
-drc

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.yeti-dns.org/pipermail/discuss/attachments/20160329/ae01f52f/attachment.bin>


More information about the discuss mailing list