any KSK can be used as a TA. there is no way to know - unambigiously -
that any given KSK is not being used as a TA in some validator.
however, your assertion that at KSK should -never- be rolled unless
compromise is known or strongly suspected is -BAD- from an operational
and liklely from a trust perspective.
your selection of 12-13 months and 25 years are suspect. Can you provide
the underlaying bias for these tiemframes?
--bill
On Sun, Sep 28, 2008 at 09:14:34PM -0700, Paul Hoffman wrote:
> In the last paragraph of 3.1.1, remove the last sentence ("Although,
> given a long enough key..."). Replace it with the following
> paragraphs:
> There are two schools of thought on rolling a KSK that is not a
> trust anchor:
> - It should be done regularly (possibly every few months) so that
> a key rollover remains an operational routine.
> - It should only be done when it is known or strongly suspected
> that the key has been compromised in order to reduce the
> stability issues on systems where the rollover does not happen
> cleanly.
> There is no widespread agreement on which of these two schools of
> thought is better for different deployments of DNSSEC. There is a
> stability cost every time a non-anchor KSK is rolled over, but it
> is possibly low if the communication between the child and the
> parent is good. On the other hand, the only completely effective
> way to tell if the communication is good is to test it
> periodically. Thus, rolling a KSK with a parent is only done for
> two reasons: to test and verify the rolling system to prepare for
> an emergency, and in the case of an actual emergency.
>
> Because of the difficulty of getting all users of a trust anchor to
> replace an old trust anchor with a new one, a KSK that is a trust
> anchor should never be rolled unless it is known or strongly
> suspected that the key has been compromised.
>
> Remove the first paragraph of 3.3; it is now covered in 3.1.1 (and it
> was wrong about the cryptography).
>
> Change the second paragraph of 3.3 to:
> From a purely operational perspective, a reasonable key effectivity
> period for KSKs that have a parent zone is 13 months, with the
> intent to replace them after 12 months. An intended key
> effectivity period of a month is reasonable for Zone Signing Keys.
> This annual rollover gives operational practice to rollovers.
>
> Ignoring the operational perspective, a reasonable effectivity
> period for KSKs that have a parent zone is 25 years or longer.
> That is, if one does not plan to test the rollover procedure, the
> key should be effective essentially forever, and then only rolled
> over in case of emergency.
>
> In the first paragraph of 4.2, replace the first two sentences with:
> Regardless of whether a zone uses periodic key rollovers in order
> to practice for emergencies, or only rolls over keys in an
> emergency, key rollovers are a fact of life when using DNSSEC.
>
> --Paul Hoffman, Director
> --VPN Consortium
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
