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

[Shane Kerr]

David,

At 2016-06-06 07:43:43 -0700
David Conrad <drc at virtualized.org> wrote:

> > 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 risk analysis is a very reasonable and very tricky undertaking.
Obviously the risk is lowest if you NEVER, EVER roll the KSK. But as
soon as you do roll then you have to look at the amortized costs - like,
is 0.1% breakage every year for 10 years worse or better than 1%
breakage once? (Math says it is very slightly better... but the
subjective feeling of things always breaking may be worse, or the
subjective feeling of having "everything" fall apart on some flag day
may be worse... ug. This stuff is hard.) 

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

Yes, absolutely. Also very tricky since we don't have any data or even
anecdote to guide us.

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

Certainly not everything about systemd's shiny new resolver is great,
but I'm not convinced that the systemd approach to the KSK is a
horrible one. (By "the systemd approach" I mean not having RFC 5011
support.) I trust my OS vendor to be on top of updating everything
else, so this isn't a big deal for me or probably most users or
administrators. In fact, my systems check for security updates every
day. I'd be nervous about a system that was unpatched for a few days,
much less a few years. :)

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

Hm... interesting point. The Let's Encrypt root CA expires in 2021 (at
least, I think so based on my interpretation of what my browser is
telling me).

AIUI the CA model basically involves convincing a very small number of
distributors to update trust - browser developers and a few OS
vendors/distributors.

So, yes, there are radically different notions about how DNS and X.509
manage trust, but the fundamental idea of getting good at something by
doing it all the time still applies. Rebooting machines now and then is
an excellent idea, otherwise you can't know if they will restart
properly. :) (I am terrified of a VPS that I run with 388 day uptime.
I keep meaning to reboot it when I have a bit of time to deal with
the possible breakage that will result...)  
 
> > 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.

Okay, that makes sense. Certainly I realize that there was some urgency
to getting the root signed, so while there are some issues resulting
from decisions made 6 or 7 years ago, those decisions had to be made.
 
> 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.

Yup! After the initial signing I think the DNS world kind of breathed a
sigh of relief, when probably we should have not. Certainly in the IETF
there was a lot of fatigue at the long road to DNSSEC, so I guess it is
understandable.

I think (hope) that after the first KSK roll that there will be a lot
of work and preparation right away for the second KSK roll.

Cheers,

--
Shane
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 181 bytes
Desc: OpenPGP digital signature
URL: <https://lists.dns-oarc.net/pipermail/dns-operations/attachments/20160607/9a02e9ac/attachment.sig>