On Thu, Jan 21, 2010 at 01:57:49PM -0800, David Conrad wrote: > > First time a scheduled roll botches, any rational organization would > institute policies and processes to ensure that such a botch does > not reoccur. First time a scheduled roll botches with a new > outsourced contractor, any rational organization would institute > policies and processes to ensure that such a botch does not reoccur.
You have worked in more enlightened organizations than I, then. In my experience, with a lot of this sort of outsourcing, what will happen is that the outsourcing company will produce an incident report detailing the many ways the overworked drone who didn't know what he was doing screwed up, why their JD Power or whatever surveys prove that this never happens to them, and the 40 meetings that will be held to ensure that even though this was in fact an impossible event, it will never happen again. In an organization that actually knows what it is doing technologically, I'm sure you're right. In an organization that doesn't actually care about running its systems because everyone there has something else they're really doing, DNSSEC will be handed out to someone else. The people in that organization will have _no clue_ how to evaluate the goodness or badness of the DNSSEC procedures of said contractors. Or maybe one person in the company will, but he will be doing the work of three people and won't have time to pay close attention to any of this. The DNS is _not important_ to most of the people who have to rely on it, any more than the details of my plumbing system are something I think about every time I wash my hands (and yes, I have replaced my own pipes). Asking people to roll their keys all the time is like telling them that they need to do annual maintenance checking the washers in all their sinks, to make sure that they're not having leaks. Good, sane practice; but they're not going to do it. They'll notice when a drip starts, and that day they'll call a plumber. > There is a reason people have "fire drills" on a periodic schedule. When we have fire drills, in my experience, we don't actually set off the alarms and run the sprinklers (or set the building on fire). We do it in a controlled, test way, with a mechanism to warn the fire department and so on. And actually, in many places, everyone knows when a fire drill is happening. We don't seem to have mechanisms for all this stuff everywhere in the DNS. Finally, there are places where fire drills practically never happen -- I've never once been in a movie theatre where a fire drill happened during a show, for instance. And for good reason: the risk of setting off a panic and hurting people is much greater than the risk that people won't know what to do in case of a real fire. I'm not trying to say, "Never roll your keys under any circumstances." I am arguing, however, that the advice in a document about how to manage your systems has to contain second-order advice about evaluating risk and reward, if we want that advice to be helpful. Rolling keys entails some risk, and if that risk is greater than the combination of the risk that the key is going to be compromised in the key lifetime and the risk reduction from key rolling practice, then the person deciding to do the key roll anyway is actually being irresponsible: they're taking greater risk than need be. Different environments entail different results for that risk evaluation, because the keys are not all of the same value. The keys for mytinycornerof.universe.example.com are just not as valuable as the keys for the root, and that means I have to make trade-offs that might be different than those for the root. Isn't that obvious? A -- Andrew Sullivan a...@shinkuro.com Shinkuro, Inc. _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
