Michael StJohns <[email protected]> writes:
> Much improved - but still some disconnects (all review is de novo):
That's Mike. All good comments. I've attached responses and actions
(or inactions) below and will push a new version shortly as well.
Wes Hardaker
Table of Contents
_________________
1 DONE In Abstract - insert "by the publisher" after "must be followed" -
2 DONE Section 2 - first para - "from the DNSKEY publication and
3 DONE in 3 - lastSigExpirationTime - replace the first sentence with "The
4 TODO in 3 - sigExpirationTimeRemaining - two items:
5 DONE in 5.1.1 T+10 - replace "they have now expired" with "the signatures
6 WONTDO Delete 6.1.4 - activeRefreshOffset - its a nonsensical value that is
7 WONTDO 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case
8 WONTDO fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - the
9 WONTDO In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of
10 DONE Section 6.3 has one too many activeRefresh terms in both formulas -
11 WONTDO Guidance about key compromise
12 DONE Appendix A - fix the calculations to match up with the section 6
formulas.
1 DONE In Abstract - insert "by the publisher" after "must be followed" -
=========================================================================
this is clear later, but should be clear in the abstract.
2 DONE Section 2 - first para - "from the DNSKEY publication and
================================================================
revocation's point of view" is unusual phrasing. I'm not sure how a
publication or revocation has a point of view. I think you meant from
the trust anchor publisher or SEP DNSKEY publisher's point of view?
+ Response: I did indeed mean SEP publisher; fixed
3 DONE in 3 - lastSigExpirationTime - replace the first sentence with "The
===========================================================================
latest value (i.e. the future most date and time) of any RRSig
Signature Expiration field covering any DNSKEY RRSet containing only
the old trust anchor(s) that are being superseded." - This may still
need wordsmithing or expansion.
4 TODO in 3 - sigExpirationTimeRemaining - two items:
=====================================================
"latestSigExpirationTime" -> lastSigExpirationTime. and measured from
when? I think its "when the addWaitTime calculation is run" or
"lastSigExpirationTime - now"
+ Response: I think it's fairly self evident from the text that it's
"when used", which is indeed at least during addWaitTime
calculation. But it's more conceptual and 'the amount of time
remaining' I think is pretty clear to mean "from now". I thought
about adding something like "from now" into the sentence, but that
didn't seem better to me and added unneeded or complexity to the
sentence. Suggestions?
5 DONE in 5.1.1 T+10 - replace "they have now expired" with "the signatures
===========================================================================
have now expired" - clarify context.
6 WONTDO Delete 6.1.4 - activeRefreshOffset - its a nonsensical value that is
==============================================================================
only valid from the resolver's point of view. For a given
publisher/authoritative server - there will be as many
activeRefreshOffsets as there are resolvers so the publisher must
assume the worst case of activeRefresh.
+ Response: I disagree here. This was put in after a discussion with
Matthijs Mekking to specifically address the case where the polling
period may not end up right in time-step with the addHoldDownTime.
The end result is that when a RFC5011 resolver is polling at a
different frequency based on the activeRefresh time. We are
defining a minimum mathematically defined safety value and this
value is calculatable, so it should remain. There is a hint of
guidance text that says you can set it to activeRefresh for
simplicity if you want. But the math-line is before a full second
activeRefresh. But the value itself needs to be included to account
for the odd frequency slippage.
TL;DR: this isn't a guidance document, it's a mathematical line
document
7 WONTDO 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case
============================================================================
value. (Wait Timer Based Calculation)
8 WONTDO fix 6.2.1.1 delete the term for addHoldDownTime % activeRefresh - the
==============================================================================
"2 * activeRefresh" in the previous term covers both the activeRefresh
interval at the beginning of the acceptance period and the
activeRefresh interval at the end.
9 WONTDO In 6.2.2 - same changes as for 6.2.1 and 6.2.1.1 (e.g. get rid of
==========================================================================
activeRefreshOffset throughout).
,----
| v activeRefresh v
| addHoldDownTime v activeRefresh v safetyMargin v
|
|
|-----------------------|-------------------------------------|-------------------------------------|--------------------------|----------------|
|
| lastSigExpirationTime^^^ acceptanceStarts ^^^
| acceptance begins to complete^^ earliestSafe^^^
`----
After the second activeRefresh interval all of the well behaved and
well connected resolvers should have the new trust anchor. The
safetyMargin adds some space for poorly behaving or intermittently
connected resolvers or those with some drops in queries.
10 DONE Section 6.3 has one too many activeRefresh terms in both formulas -
===========================================================================
here are the corrected ones:
remWaitTime = sigExpirationTimeRemaining + activeRefresh +
safetyFactor
remWallClockTime = lastSigExpirationTime + activeRefresh +
safetyFactor
Basically, assuming no attacker, and no drops, all well-behaved
resolvers will see the revocation after one activeRefresh interval
from the time of publication. Add the safety factor to take care of
the slackers. This is a fine value for normal revocations where
you're pretty sure that the key hasn't been compromised.
There is no hold-time timer for revocation - they take effect
immediately upon receipt and validation.
11 WONTDO Guidance about key compromise
=======================================
In the case of a key compromise, I would suggest that the revoked key
be published for the same interval as you would use for adding a new
trust anchor. (But of course, this won't actually matter all that
much if you only have a single trust anchor....)
+ Good advice to put in an general advice document in the future
12 DONE Appendix A - fix the calculations to match up with the section 6
formulas.
==================================================================================
--
Wes Hardaker
USC/ISI
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
