On 11/29/2017 5:29 PM, Wes Hardaker wrote:
internet-dra...@ietf.org writes:
A New Internet-Draft is available from the on-line Internet-Drafts
directories. This draft is a work item of the Domain Name System
Operations WG of the IETF.
FYI, this contains the restructuring talked about during IETF100/dnsop
as well the new safetyMargin concepts proposed by MSJ. I haven't done a
complete double check on all my restructuring yet, so for the chairs
especially: there will likely be a -09 very soon ready for second WGLC,
but not this one.
Hi -
Much improved - but still some disconnects (all review is de novo):
In Abstract - insert "by the publisher" after "must be followed" - this
is clear later, but should be clear in the abstract.
in 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?
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.
in 3 - sigExpirationTimeRemaining - two items: "latestSigExpirationTime"
-> lastSigExpirationTime. and measured from when? I think its "when
the addWaitTime calculation is run" or "lastSigExpirationTime - now"
in 5.1.1 T+10 - replace "they have now expired" with "the signatures
have now expired" - clarify context.
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.
In 6.2.1 - replace activeRefreshOffset with activeRefresh - worst case
value.
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.
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.
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.
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)
Appendix A - fix the calculations to match up with the section 6 formulas.
Later, Mike
___
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
