At 9:42 -0700 4/24/09, Paul Hoffman wrote:
a) KSKs longer than ZSKs because KSKs are thought of as needing to be stronger
b) KSKs the same strength as ZSKs because neither should be weak
enough to be attacked
I prefer (b), but (a) keeps coming up in this discussion.
The reason (a) is held as conventional wisdom by some set of folks...
In the beginning we had keys. In the early workshops we realized
that there were two kinds of delegations where keys mattered.
Delegations we made to ourselves and delegations made to us from
someone else. (In the workshops the leader was the DNS parent to all
of the participants' child zones.)
We realized when we tried to do key rolls (because we knew that keys
wore out) that it was much easier to change keys when it was us
delegating to our self than when we had to run down the instructor
(who was generally looking at a bug rooted in the specification,
code, or configuration).
Stirring this around in the primordial soup, the ZSK and KSK was
born. (Eliding the rationale.) And along the way the SEP flag was
born.
In modern times this has translated into this issue. When it comes
time to design our ZSK roll, we realize all of the steps involve
internal matters. Running a key generation task first. Moving the
private key files around is the next task. Removing the old key is
the last step. We can predict the time it takes to do all of the
steps, we can do all this unannounced, when can even target all the
normal ops to be started via cron.
When it comes to a KSK, we have to involve an external entity. When
it comes to planning and writing the tasks, we (at this time) have no
idea of the interface our parent will use (if they ever do sign) and
what the response time will be - will if be < 5 minutes or > 5 days?
As architect, I really don't care if the KSK is longer than the ZSK,
I don't care if the KSK is stronger than the ZSK. What matters is
that I just have to roll the KSK much less and have it be a less
important operation in my activities. I can be more specific about
ZSK life cycle, it's the KSK life cycle that has a huge unknown (the
relationship with the parent).
As someone who has been developing DNSSEC I certainly understand (b).
There was a time the KEY RR had a signatory field which was thought
to be a reflection of strength - RFC 2065, section 3.3:
Bits 12-15 are the "signatory" field. If non-zero, they
indicate that the key can validly sign RRs or updates of the same
name. If the owner name is a wildcard, then RRs or updates with any
name which is in the wildcard's scope can be signed. Fifteen
different non-zero values are possible for this field and any
differences in their meaning are reserved for definition in
connection with DNS dynamic update or other new DNS commands. Zone
keys always have authority to sign any RRs in the zone regardless of
the value of this field. The signatory field, like all other aspects
of the KEY RR, is only effective if the KEY RR is appropriately
signed by a SIG RR.
We realized overtime that all keys are equal when it comes to
strength because the validation chain caused "fate sharing." I.e.,
if the zone above you has a 512 bit key, your 1024 and 2048 kit keys
aren't all that "valuable" if you are optimizing for
crypto-mathematical wizardry. I.e., KSKs are no more special than
ZSKs in the validation chain.
The conventional wisdom to make the KSK longer is that we just want
to avoid frequently having to bug our parent. It wasn't rooted in
thinking the KSK is any more special cryptographically.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar You can leave a voice message at +1-571-434-5468
Getting everything you want is easy if you don't want much.
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
