At 6:23 AM -0700 9/29/08, Wes Hardaker wrote:
>>>>> On Sun, 28 Sep 2008 21:14:34 -0700, Paul Hoffman
<[EMAIL PROTECTED]> said:
Overall I think the changes seem reasonable. However, I don't think
everything is taken into account... I understand the desire for
removing the specified timing associated with key-age based on modern
analysis. But there are other reasons for needing to roll keys besides
just emergencies and emergency practice. Specifically:
- algorithm changes (future algorithms may become more popular and
supported by more tool sets than current ones)
- key length changes required due to advances in cryptographic attacks
- ownership changes (think of a zone name buy-out... the new owner will
certainly not want to use the same key since I doubt they'll trust the
original owner much but they will want to use it long enough for a
reasonable properly timed rollover to occur).
- parent relationship requirement changes (it's possible certain
registrar's could enforce using a particular kind of key because
that's how they're infrastructure is set up and if you change
registrar's you may have to change your keying attributes).
Good points. I would put the second and third of those into the
"emergency" category, but not due to compromise. If people are liking
the changes in general, adding the above would be good. It sounds
like maybe there should be a separate sub-section on rollover theory
instead of just two paragraphs.
You make the assumption (in a few places) that you can control who uses
your key as a trust anchor here. IE, if your parent is signed you
shouldn't need to worry about your key as a trust-anchor. Although nice
in theory, it may not meet real-world operational practice. In many
cases it is probably true that your key will not be used as a TA, in
other cases it's certainly false.
This is a very good point, but I'm not sure how to deal with it in
4641bis. If you as a key owner need to worry about this, you'll
always have to do the harder work that trust anchors do. Maybe this
can be mentioned a few places in the document but made part of the
decision tree.
Now that you mention this, the opposite is also true today. TLDs who
today need to be planning to be trust anchors due to the lack of a
signed root also want to plan for the future when they have a parent.
Worse, they get to deal with TARs, which are operationally halfway
between a trust anchor and parent. This is well worth adding to
4641bis as well.
PH> Ignoring the operational perspective, a reasonable effectivity
PH> period for KSKs that have a parent zone is 25 years or longer.
^^^^^^^^
PH> That is, if one does not plan to test the rollover procedure, the
PH> key should be effective essentially forever, and then only rolled
^^^^^^^
PH> over in case of emergency.
I agree that 25 years is long. I disagree, however, that it's safe to
round it up to forever (infinite). Maybe wording along the lines of:
"...effective longer than most operational environments exist without
change" or something like that, which is really what you're trying to
imply by using 'forever'.
Yes, that is a more accurate way to deal with "forever".
--Paul Hoffman, Director
--VPN Consortium
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
