Joe Abley wrote:
[from a namedroppers thread, re-pointed as per Olaf's suggestion below]
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.
The EKR's concern and the operational benefits are compatible. I.e. roll
the ZSK per operational requirements, and use a ZSK key size adequate
for longer-term resistance to brute force cryptanalysis.
Regards,
- Thierry Moreau
Joe
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
