I didn't think this could get worse. I was wrong.
I can't support any version of this document for publication. In the
same way that activeRefreshOffset is a nonsensical value so to are
driftSafetyMargin and timingSafetyMargin.
1) Drift happens per query.
2) Any drift that happens related to the multiple queries in the
addHoldDown interval can safely be ignored with respect to its impact on
the overall wait time for the publisher. (e.g. all the drift is going
to do is change the phase of the last query in the interval with respect
to the end of the addHoldDown time)
3) The only other drift that may be of interest is the drift at the
beginning and end of the queryInterval where the end of the interval is
the beginning of the addHoldDown interval. Given that a typical drift is
something like 1-60 seconds it can safely be ignored related to all the
other stuff.
Timing safety margin is based on the nonsensical driftSafetyMargin and
activeRefreshOffset and is then by definition also nonsensical.
(And yes, I realize that Wes has set driftSafetyMargin to activeRefresh
meaning that calculated results are identical to what I want, but
there's no analysis that supports the use of a driftSafetyMargin and
this just seems to be sleight of hand to replace activeRefreshOffset
with a term that has a value activeRefresh... *pounds head against wall*)
Please delete 6.1.6, 6.,1.7 and 6.1.8 and fix the formulas accordingly.
Again:
addWaitClockTime = lastSigExpirationTime + activeRefresh +
addHoldDownTime + activeRefresh + safetyMargin (which now seems to be
labeled retrySafetyMargin).
Mike
On 12/19/2017 1:49 PM, [email protected] wrote:
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.
Title : Security Considerations for RFC5011 Publishers
Authors : Wes Hardaker
Warren Kumari
Filename :
draft-ietf-dnsop-rfc5011-security-considerations-10.txt
Pages : 19
Date : 2017-12-19
Abstract:
This document extends the RFC5011 rollover strategy with timing
advice that must be followed by the publisher in order to maintain
security. Specifically, this document describes the math behind the
minimum time-length that a DNS zone publisher must wait before
signing exclusively with recently added DNSKEYs. This document also
describes the minimum time-length that a DNS zone publisher must wait
after publishing a revoked DNSKEY before assuming that all active
RFC5011 resolvers should have seen the revocation-marked key and
removed it from their list of trust anchors.
This document contains much math and complicated equations, but the
summary is that the key rollover / revocation time is much longer
than intuition would suggest. If you are not both publishing a
DNSSEC DNSKEY, and using RFC5011 to advertise this DNSKEY as a new
Secure Entry Point key for use as a trust anchor, you probably don't
need to read this document.
The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dnsop-rfc5011-security-considerations/
There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dnsop-rfc5011-security-considerations-10
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-10
A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-10
Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop
