[dns-operations] Why roll the KSK? (was Sad news today: systemd-resolved to be deployed in Ubuntu 16.10)

[David Conrad]

Shane,

> the question long
> ago when the root signing process was being developed was whether we
> should roll:
> 
> 1. only when needed (Florian's position),
> 2. frequently, or
> 3. every now and then (the current IANA KSK DPS)
> 
> The motivation behind #1 is why bother if things are working?

Partly this and partly given every time you touch the KSK you increase the (extremely low) risk of a somewhat catastrophic failure mode (specifically, having to cold reboot every validator on the planet), minimizing touching the KSK would seem like a good thing. Oh, and partly the "validating resolver on the shelf" problem (that is, right now if you have a validator from 6 years ago that's still in its shrink wrap, you can still take it out, plug it in and it will work. That will stop when we roll the key.)

> The motivation behind #2 is that if you don't make it part of practice,
> then it won't work when you need to use it.

Yes, but the question becomes "how frequent is frequent enough to gain this benefit?"

> The current concerns about
> widespread DNSSEC breakage when the KSK rolls next year seem to
> indicate that this is a valid concern.

Given the approach systemd appears to be taking, I have some doubt that even rolling frequently will cure stupidity.

> A model like Lets Encrypt, which
> requires new certificates every 90 days, seems more and more like a
> good idea in retrospect. So you wouldn't need RFC 5011, but you would
> have to have *some* automated way to keep your DNS trust anchor up to
> date.

A slight difference: if the folks at Let's Encrypt break something, there are a few (hundreds) of other trust roots to rely on.  Also, while I don't actually know, I'd be a bit surprised if the root CA for Let's Encrypt expires after 90 days. I'd be interested to know (but am too lazy to go look) what the lifetime of their root certificate is.

> The motivation behind #3 is... um. Well, I don't actually know. It
> seems like the worst of all possible worlds. :-P

It is fascinating to me that embarrassing quotes and pictures last forever on the Internet yet technical discussions seem to have a half-life measured in months.

Summarizing the arguments for #3 I recall:

1) in 2010, 5011 had seen limited deployment. As the chosen automated way of rolling the key, we had a choice:
a) delay signing the root until 5011 had seen more deployment (potential chicken-or-egg problem);
b) sign and roll the key without 5011 (risking encouraging resolver operators to say "come back when you're done dicking around with the key" and discouraging 5011 use); or
c) sign and roll the key after 5011 had seen reasonable deployment.
2) in 2010, after the Kaminsky method for cache poisoning was discovered, we wanted to strongly encourage DNSSEC and it was felt by some that rolling the key frequently would actively discourage resolver operators from turning on DNSSEC because it changed (increased) the operational workload.

Hope this helps.

BTW, it is probably worth noting that while plans are afoot to do the initial root key roll, we (the Internet community as a whole) have not figured out when the roll after that (or the roll after that, etc) will/should be.

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: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160606/7acdbd10/attachment.sig>