[DNSOP] Updates to the KSK Sentinel document - draft-ietf-dnsop-kskroll-sentinel-05

[Warren Kumari <[e-mail]>]

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:  <[e-mail]>
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 <[e-mail]>, Geoff Huston <[e-mail]>,
Warren Kumari <[e-mail]>



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