On Tue, Dec 19, 2017 at 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
>
>
6.1.7.  driftSafetyMargin

"Moving past the theoretical model parameters above, we not that clock
drift"

"not" -> "note"

-- 
Bob Harold
_______________________________________________
DNSOP mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dnsop

Reply via email to