Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel
Hi The call for adoption for this has ended and the groups has requested adoption. I will contact the authors about updating their draft with the new name as well as addressing open issues during the call. tim On Thu, Nov 16, 2017 at 3:23 AM, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
Re: [DNSOP] Call for Adoption: draft-huston-kskroll-sentinel
I support adoption of this work and I'm willing to review and contribute as needed. mehmet On Thu, Nov 16, 2017 at 12:23 AM, tjw ietf wrote: > All > > The author has rolled out a new version addressing comments from the > meeting on Monday, and we feel it’s ready to move this along. > > This starts a Call for Adoption for draft-huston-kskroll-sentinel > > The draft is available here: > https://datatracker.ietf.org/doc/draft-huston-kskroll-sentinel/ > > Please review this draft to see if you think it is suitable for adoption > by DNSOP, and comments to the list, clearly stating your view. > > Please also indicate if you are willing to contribute text, review, etc. > > This call for adoption ends: 30 November 2017 23:59 > > Thanks, > tim wicinski > DNSOP co-chair > > ___ > DNSOP mailing list > DNSOP@ietf.org > https://www.ietf.org/mailman/listinfo/dnsop > > ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
[DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-00.txt
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 : A Sentinel for Detecting Trusted Keys in DNSSEC Authors : Geoff Huston Joao Silva Damas Warren Kumari Filename: draft-ietf-dnsop-kskroll-sentinel-00.txt Pages : 8 Date: 2017-12-10 Abstract: The DNS Security Extensions (DNSSEC) were developed to provide origin authentication and integrity protection for DNS data by using digital signatures. These digital signatures can be verified by building a chain of trust starting from a trust anchor and proceeding down to a particular node in the DNS. This document specifies a mechanism that will allow an end user to determine the trusted key state of the resolvers that handle the user's DNS queries. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-00 https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-00 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
Re: [DNSOP] I-D Action: draft-ietf-dnsop-rfc5011-security-considerations-08.txt
On Friday, December 08, 2017 06:27:07 AM Michael StJohns wrote: > To try this out, let’s use a ttl of 28 hours and an expiration of 7 days to > get an active refresh as below. Mike, I very much appreciate the analysis of the text and the proposed method that you've done. I am picking this message as my entry point to this thread even though my comments are also applicable to Message-ID: <6d239b9a-fd1e-46a3- c705-6851dd8ff...@nthpermutation.com>. > Take an activeRefresh of 14 hours (giving a fast retry of 2.8 hours and an > addHoldDown time of 30 days (720 hour). That gives you an > activeRefreshOffset of 6 hours. A perfect resolver will make 51 queries > in 714 hours and the last triggering query at 728 hours. > > Assume a 4% failure rate (to make the math easy) in queries and assume the > first retry always works. Which adds approx two fast retry intervals to the > time making the total time to do 51 queries 719.8 hour for an actual offset > of .2 hours. The next and last query needed to take place to trigger the > trust anchor installation will take place at 733.8 hours. > > The point is that retransmission drift makes the whole concept of > activeRefreshOffset nonsensical in any population of resolvers with any > losses at all. Authors, I suggest and request that you both model and simulate the proposed method, along the lines Mike has done in this thread but with more than one set of parameters and conditions, in order that the second-set-of-eyes can be readily provided by more than one reviewer. This timing based approach to online DNSSEC signing key changes is subtle beyond anybody's expectations, and because it will be used by the root zone, it is vital that we do more than simply whiteboard our proposed methods. -- P. Vixie -- P. Vixie ___ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
