The authors are more than happy to change the name to that... W On Wed, Jul 18, 2018 at 9:13 AM Ólafur Guðmundsson <olafur=40cloudflare....@dmarc.ietf.org> wrote: > > > Hi > i read this document over with fresh eyes and tried to ignore any history. > > Summary: Publication considered harmful > > Reasons: This document calls itself "Security Considerations" but in reality > all it is covering is "Publication considerations by Authority" > the document does not cover at all the consumption of RFC5011 events by > resolvers which IMHO are the more important part of the protocol. > > Olafur > > > On Mon, Jul 16, 2018 at 8:49 AM, <internet-dra...@ietf.org> 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-13.txt >> Pages : 20 >> Date : 2018-07-16 >> >> 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. This document updates RFC7583 by >> adding an additional delays (sigExpirationTime and >> timingSafetyMargin). >> >> 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-13 >> https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-rfc5011-security-considerations-13 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-rfc5011-security-considerations-13 >> >> >> 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 >> DNSOP@ietf.org >> https://www.ietf.org/mailman/listinfo/dnsop > > > > > -- > Ólafur Gudmundsson | Engineering Director > www.cloudflare.com blog.cloudflare.com > _______________________________________________ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop
-- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
