Dear all, I've just posted an update of the KSK Sentinel document -- this is thanks to the contributions from a number of DNSOP participants - https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/
Petr, Paul and Mary[0] ^h^h^h^h Duane deserve special thanks for submitting pull requests (https://github.com/APNIC-Labs/draft-kskroll-sentinel/pulls?q=is%3Apr+is%3Aclosed) , and issues (https://github.com/APNIC-Labs/draft-kskroll-sentinel/issues?q=is%3Aissue+is%3Aclosed ) Petr added an implementation of this to the Knot resolver (in the ta_sentinel module - https://github.com/CZ-NIC/knot-resolver/tree/1b36d2d4e0ba1446dd71a9a53aef54b7c93ca88d/modules/ta_sentinel) - we swapped the name out from under him, and so it needs to be updated, but implmenting it provided very useful feedback. The commit history is here: https://github.com/APNIC-Labs/draft-kskroll-sentinel/commits/master and the high level change log is: From -04 to -05: o Incorporated Duane's #10 o Integrated Petr Spacek's Issue - https://github.com/APNIC-Labs/ draft-kskroll-sentinel/issues/9 (note that commit-log incorrectly referred to Duane's PR as number 9, it is actually 10). From -03 to -04: o Addressed GitHub pull requests #4, #5, #6, #7 #8. o Added Duane's privacy concerns o Makes the use cases clearer o Fixed some A/AAAA stuff o Changed the example numbers o Made it clear that names and addresses must be real From -02 to -03: o Integrated / published comments from Paul in GitHub PR #2 - https://github.com/APNIC-Labs/draft-kskroll-sentinel/pull/2 o Made the keytag be decimal, not hex (thread / consensus in https://mailarchive.ietf.org/arch/msg/dnsop/ Kg7AtDhFRNw31He8n0_bMr9hBuE ) From -01 to 02: o Removed Address Record definition. o Clarified that many things can cause SERVFAIL. o Made examples FQDN. o Fixed a number of typos. o Had accidentally said that Charlie was using a non-validating resolver in example. o [ TODO(WK): Doc says keytags are hex, is this really what the WG wants? ] o And active key is one that can be used *now* (not e.g AddPend) From -00 to 01: o Added a conversational description of how the system is intended to work. o Clarification that this is for the root. o Changed the label template from _is-ta-<key-tag> to kskroll- sentinel-is-ta-<key-tag>. This is because BIND (at least) will not allow records which start with an underscore to have address records (CNAMEs, yes, A/AAAA no). Some browsers / operating systems also will not fetch resources from names which start with an underscore. Thanks, W [0]: https://en.wikipedia.org/wiki/Peter,_Paul_and_Mary ---------- Forwarded message ---------- From: <internet-dra...@ietf.org> Date: Mon, Mar 5, 2018 at 1:31 PM Subject: New Version Notification for draft-ietf-dnsop-kskroll-sentinel-05.txt To: Joao Silva Damas <j...@apnic.net>, Geoff Huston <g...@apnic.net>, Warren Kumari <war...@kumari.net> A new version of I-D, draft-ietf-dnsop-kskroll-sentinel-05.txt has been successfully submitted by Warren Kumari and posted to the IETF repository. Name: draft-ietf-dnsop-kskroll-sentinel Revision: 05 Title: A Sentinel for Detecting Trusted Keys in DNSSEC Document date: 2018-03-05 Group: dnsop Pages: 14 URL: https://www.ietf.org/internet-drafts/draft-ietf-dnsop-kskroll-sentinel-05.txt Status: https://datatracker.ietf.org/doc/draft-ietf-dnsop-kskroll-sentinel/ Htmlized: https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-05 Htmlized: https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-05 Diff: https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-05 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 and third parties to determine the trusted key state for the root key of the resolvers that handle that user's DNS queries. Note that this method is only applicable for determing which keys are in the trust store for the root key. There is an example / toy implementation of this at http://www.ksk- test.net . [ This document is being collaborated on in Github at: https://github.com/APNIC-Labs/draft-kskroll-sentinel. The most recent version of the document, open issues, etc should all be available here. The authors (gratefully) accept pull requests. Text in square brackets will be removed before publication. ] [ NOTE: This version uses the labels "kskroll-sentinel-is-ta-<key- tag>", "kskroll-sentinel-not-ta-<key-tag>"; older versions of this document used "_is-ta-<key-tag>", "_not-ta-<key-tag>". Also note that the format of the tag-index is now zero-filled decimal. Apolgies to those who have began implmenting.] 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. The IETF Secretariat -- 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
