On Fri, Jan 22, 2010 at 12:57:13AM +0000, Jim Reid wrote:
> invoked from time to time in the live environment. And not just for
> drills.
That sounds rather like a claim that we need to go around and set
buildings on fire from time to time (or have levees break, or cause 7+
Richter-scale earthquakes, or pick your analogy) in order to make sure
that the procedures are in place.
It is simply not true that everything needs to be done "for real" in
order to be sure it can be done. I don't think we should have live
nuclear-weapon ICBM tests just to see whether the reaction procedures
of the local elementary school are up to snuff. As I've now said
several times, the risk of some activities is greater than the reward
from seeing how well your operation of that activity follows the
plans.
The question here is how great the risk of key rolling is: is it more
like live ICBM tests, or is it more like changing your underwear (the
procedures for which I'm sure we all hope everyone keeps in good
nick)? I claim the answer to that question is, "It depends," and we
need to give people advice on how to decide where on the
nuclear-war/underpants scale they lie. I think EKR and Paul have
suggested ways to say that. I enclose below some additional
long-winded text in case any of it can be useful.
Keys in use do not become weaker with continued use, and there are
not strong arguments from a cryptographic point of view that keys
need to be rolled frequently or even with any regularity.
Given the state of the cryptographic art as of this writing, the
chances of a key (selected in accordance with the recommendations
in this Section 3) being broken by cryptanalysis is exceeding low.
It is important to evaluate continuously that risk. When making
an evaluation, it is important to remember that the main question
is one of cost versus value:
1. What will it cost an attacker to crack the key?
2. What will the benefit to the attacker be (i.e. what is the
value of the key)?
3. How long can the attacker realistically expect to gain
from the attack?
To take a deliberately bad example, if it costs $1,000,000 to
crack the key once a month, and the attacker can only actually use
the compromised key one time before being detected, then the value
of that single use needs to be at least $1,000,000 (however one
calculates that value) to make the attack worth performing.
Each key rollover comes with some risks and rewards. Every key
rollover runs a small risk that the new key will not be available
somewhere in time for the old key to be removed, if only because
of the possibility that a validator has misconfigured the old key
as a preferred trust anchor. Errors in the key rollover
procedures or their execution can also lead to the new key not
being available in time. If some validating resolver attempts to
use the old key, and cannot (or will not, by configuration) use
the new key after the rollover has completed, then that validator
will treat the zone as bogus.
Sites that have well-automated and carefully-tested key rollover
procedures, particularly if the site is well-monitored from
diverse networks, are somewhat less likely to face long-term
outages due to key rollover problems; at the same time, such
high-value zones are more likely to suffer embarrassment from a
botched key rollover. By similar reasoning, a small site for
which DNSSEC is at most a part-time occupation for one staff
member might run great risk of outage during a key rollover, just
because the testing and detection of DNS issues may not be as
complete as at a larger site. Most sites will fall in a continuum
between these extremes. Determining policy around key rollover --
whether to do it, how frequently if so, and whether regularly if
so -- is a matter of operational policy that needs to be
established for each site, taking into account the considerations
above.
Someone might be able to edit that into something less wordy and more useful.
A
--
Andrew Sullivan
[email protected]
Shinkuro, Inc.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
