Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-10.txt

[Michael StJohns <[e-mail]>]

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, [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dnsop