On Oct 7, 2009, at 3:22 PM, Joe Abley wrote:
On 2009-10-07, at 09:23, Olaf Kolkman wrote:
On Oct 6, 2009, at 10:08 PM, Eric Rescorla wrote:
I don't have a general position on ZSKs--perhaps it's a good idea
for
some other reason--but I don't
think that rolling the keys over at high rates provides any
significant security benefit, no matter
where in the hierarchy you're doing it.
Really this is an DNSOP issues, more specifically an issue for
RFC4641bis.
[I've added dnsop, please remove namedroppers when replying to this
note]
RFC4641 argues for frequent ZSK rollovers, the argument therein is
based on operational arguments that are (implicitly) based on
operator
acces to private keys and/or the timeline in which changes in which
the (zone) operator may need to be replaced.
I skimmed through 4641 to try and refresh my memory, but couldn't
find the discussion on ZSK rollover frequency. No doubt this is my
deficiency.
From my perspective the operational argument is that procedures
which are rarely exercised may not be exercised well when they are
needed (a backup that is not regularly tested cannot really be
relied upon; a protect path that is never used might not work when
it is needed, etc).
Frequent key rollover has the operational benefit of when you need
to do an emergency roll you know the procedures work.
From this perspective we might roll a ZSK more frequently than a KSK
because the ZSK needs to be stored on-line to facilitate re-signing
when the zone changes. With the KSK we have the option of keeping it
off-line, and arguably the risk of compromise is consequently lower.
Regular testing of the machinery is still important, however.
I am no crypto expert, but ekr's concern over the cryptographic
benefits of frequent key roll seemed entirely reasonable.
I think the operational benefit is real, however.
I find it worrying that folks intend to test or practice operational
procedures by doing it often on a live production system. What if that
test or practice fails? "Whoops, we were testing it on the live
system, we failed, good thing we called it a test"
There is also a risk involved by rolling keys over regularly.
Especially when the schedule is publicly announced. "If your attack
fails, we will have write access to the keystore _every month_, on the
1st, at exactly 3 am cest".
I fail to see the operational benefit of "Frequent Rollover Syndrome".
Roy
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
