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

Warren Kumari <warren@kumari.net> Mon, 05 March 2018 18:44 UTC

Return-Path: <warren@kumari.net>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id EADE212DA43 for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 10:44:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ghy6ZPhhtLDA for <dnsop@ietfa.amsl.com>; Mon, 5 Mar 2018 10:44:01 -0800 (PST)
Received: from mail-wm0-x22a.google.com (mail-wm0-x22a.google.com [IPv6:2a00:1450:400c:c09::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AB311200B9 for <dnsop@ietf.org>; Mon, 5 Mar 2018 10:44:01 -0800 (PST)
Received: by mail-wm0-x22a.google.com with SMTP id s206so14505163wme.0 for <dnsop@ietf.org>; Mon, 05 Mar 2018 10:44:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=IYpBdxZdvSTY8Fwj5GhB6vGrtRNWbWJhsmYKiH+px5A=; b=Ah97DvY2q4oqd9XW6zSqUXh8O3gc7swWO6iypRILyZTYeOy1vaZ7aACOa5Ln9YYSJd bZLIa8FaO1ZrdGYwM8CpttPCeTo8R0RZx+eR/IdSImiS5nxJA4f7Zq1FZFiCyx+dhd/s e+XbHofS946KgyUbZMPo5NTdQ5K4CCo8mESksoAlhRWZC01l9oQlw+Snt3wOKSYSJp/6 lA+FBjIs5Pl0hRRXF3wwZfIkmFiz8sLnML8y8usjTtAhsJhyGZomQ1gGfRRZNuq2i9Ek iEoFH3gku+vnFATs7/enb0njz7vINY7DUTUyg9xGf+dDrw7y7kfcQ5tg/N2RJCSdwILh cdGA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=IYpBdxZdvSTY8Fwj5GhB6vGrtRNWbWJhsmYKiH+px5A=; b=HRBmiVj3ywPJuHLCfowVQB1DSeb8KVvc3EQbMJfII6UrIL+DKimTeVvnx1kZo1atPQ 3UzetrZZyDKkyIkYOfJ4HEDVqOE13qKMqzPOEBg9bI1o+eGI50kKwljTukwPpBaKO+8w ITBF0qQA6ESuvVYrUdt7tfCeQ3Ye3Rk/lJm0ZU0YWI5VYBA6O2As+Nkv4HKUU+iLC9en D9x4SiXzfQGeLa/Rgk0JM0x2u88PJ/5lg1dgSGtPqiY6oFH4e793c54Ho2eeeX/ZH0b2 Wft4WUFjdAnyUAB8IcRN8twWFbIPAkfsIG6Rj0CCLd4Rup0OU9YEdft4sCNYGThq+XMf JYAw==
X-Gm-Message-State: AElRT7EqMC3qyDIpz8Ns5JM14bEknKag9cNZyvUov5cx2E+MS6R+NRj5 aS0ReQAm7DFTnLX5GTbG126qT+gcwfrtGNqrV8Tfuc4RBz8=
X-Google-Smtp-Source: AG47ELsiRXfedfVbbr6Q8+/+GKZdaHz3Edkn91YRPuG905ewfVqUA3aNIoxN0v40lxtWjTWsINgfM+RH+3dIqtQyxcY=
X-Received: by with SMTP id k71mr8524042wmd.46.1520275438649; Mon, 05 Mar 2018 10:43:58 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 5 Mar 2018 10:43:17 -0800 (PST)
From: Warren Kumari <warren@kumari.net>
Date: Mon, 5 Mar 2018 13:43:17 -0500
Message-ID: <CAHw9_iJkr-hhm5iQdzK-8CWxnd+27PLdA7Cym9A7GeTs99gjHw@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jws7SsN_Mtv3H02uDU5OrbwmhoI>
Subject: [DNSOP] Updates to the KSK Sentinel document - draft-ietf-dnsop-kskroll-sentinel-05
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Mar 2018 18:44:04 -0000

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 -

Petr, Paul and Mary[0] ^h^h^h^h Duane deserve special thanks for
submitting pull requests
, 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 -
- 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:
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 -
   o  Made the keytag be decimal, not hex (thread / consensus in
      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.


[0]: https://en.wikipedia.org/wiki/Peter,_Paul_and_Mary

---------- Forwarded message ----------
From:  <internet-drafts@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 <joao@apnic.net>et>, Geoff Huston <gih@apnic.net>et>,
Warren Kumari <warren@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
Htmlized:       https://tools.ietf.org/html/draft-ietf-dnsop-kskroll-sentinel-05

   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.