[ksk-rollover] followup of DNSSEC Workshop at ICANN64

[Dave Lawrence]

Michael Richardson writes:
> But, I don't buy the lead time argument.  If any of the N keys are
> vulnerable to brute force attack in the planned use of period, then
> all the keys are vulnerable to an adversary with 1/N more resources.
> Do you agree with this?

I completely agree with it.  Of course, it does kind of gloss over the
details, sidestepping just how high the resource bar is.  I will of
course also acknowledge that this applies equally well to the current
key, both for and against my own position.  What we're of course
trying to find is the right balance.  

It is pretty straightforward to posit that if one key is crackable by
an adversary of sufficient power in an amount of time that is not less
than the defined rolling period, that multiplying the number of such
keys extends the period of time that be spent cracking them.  I'm a
bit perplexed about how lead time can't possibly be relevant.

> Brute force is not the only attack: there are possible "Mission
> Impossible"-like exfiltration attacks against the HSM(s). Do these
> attacks depend upon how many keys there are?  I don't think so.

Right, but that was the other part of my point.  So great, you
generated 20 keys for the future, and Tom Cruise just stole the
Rootsday Device that controls them all.  Or Quantum Computerman
finally had his breakthrough and *poof* cracking time plummets.  What
good has having made that list gotten you?  We don't want those
baked-in products using the list then either.

The only thing pre-generating a bunch of keys seems to buy you is a
known schedule that you can bake into products.  While I won't say
that's valueless, for my tastes it doesn't have enough value to be
seen as a useful solution for this problem.