Subject: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-03.txt

From: [email-masked]
Date: Wed, 28 Feb 2018 11:40:39 -0800

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-03.txt
	Pages           : 13
	Date            : 2018-02-28

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 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-<tag-
   index>", "kskroll-sentinel-not-ta-<tag-index>"; older versions of
   this document used "_is-ta-<tag-index>", "_not-ta-<tag-index>".  Also
   note that the format of the tag-index is now decimal.  Apolgies to
   those who have began implmenting.]

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-03
https://datatracker.ietf.org/doc/html/draft-ietf-dnsop-kskroll-sentinel-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dnsop-kskroll-sentinel-03

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/

---

From: "Wessels, Duane" <[email-masked]>
Date: Wed, 28 Feb 2018 22:45:41 +0000

Thanks for the update.

IMO this document really needs a Privacy Considerations section and maybe also some additions to the Security Considerations.  Whereas the signals in 8145 are between the validator and the zone owner, this technique enables third parties (with either good or bad intentions) to learn something about the security configuration of recursive name servers.  Possibly all of them.

Similarly, I think the document could be more transparent and consistent about who is able to make the determinations.  For example it currently says:

   "allow an end user to determine the trusted key state"

   "allow a user to determine the state of their DNS resolution system"

   "allow us to infer a trust key state"

   "allow the client to determine the category"

I'd like to see at least in the abstract "...allows end users and third parties to determine..."

All of the examples with "2222" should now be zero padded:

$ grep ta-2222 draft-ietf-dnsop-kskroll-sentinel-03.txt 
      kskroll-sentinel-is-ta-2222.example.com.  IN AAAA 2001:db8::1
      kskroll-sentinel-not-ta-2222.example.com.  IN AAAA 2001:db8::1
   http://kskroll-sentinel-is-ta-2222.example.com/1x1.gif,
   http://kskroll-sentinel-not-ta-2222.example.com/1x1.gif).
   ta-2222.example.com name normally (it contacts the example.com
   kskroll-sentinel-not-ta-2222.example.com name.  Once again, it
   sentinel-is-ta-2222", but he cannot fetch "kskroll-sentinel-not-ta-
   sentinel-is-ta-2222", it does *not* have the (new, 2222) KSK in it's
   fetch the "kskroll-sentinel-is-ta-2222" resource, but he can fetch
   the "kskroll-sentinel-not-ta-2222" resource.  This tells Ed that his

DW

> On Feb 28, 2018, at 11:40 AM, [email-masked] wrote:
> 
> 
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop