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

From: [email-masked]
Date: Wed, 21 Feb 2018 06:03:10 -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-02.txt
	Pages           : 13
	Date            : 2018-02-21

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>".  ]

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

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

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: Petr Špaček <[email-masked]>
Date: Wed, 21 Feb 2018 15:54:46 +0100

Hello dnsop and Warren,

Section 3. Sentinel Mechanism gave me hard time while implementing this
mechanism, so I'm proposing to overhaul the section into something with
more structure.

Proposal:
(Feel free tp change and restructure it as you see fit, I'm not native
English speaker ...)

3.  Sentinel Mechanism

   DNSSEC-Validating resolvers that implement this mechanism MUST be
   performing validation of responses in accordance with the DNSSEC
   response validation specification [RFC4035].

   This sentinel mechanism makes use of 2 special labels:
   -  "kskroll-sentinel-is-ta-<tag-index>.
   -  "kskroll-sentinel-not-ta-<tag-index>.
   <tag-index> is: 4 hexadecimal digits encoding number in range
<0,2^16-1> + TODO: ABNF, zero padded from the left

   These labels trigger special processing in the resolver as specified
bellow. Labels containing "is-ta" and "not-ta" are used to answer
questions "Is (or is not, respectivaly) this the key tag a trust anchor
which the validating DNS resolver is currently trusting?"

   Processing of both labels has the very same preconditions for both
labels and differs only in last step.

3.1. Preconditions
   All following conditions must be met to trigger special processing
inside resolver code:

   a) DNS response for particular query is DNSSEC validated and result
of validation is SECURE
   b) QTYPE is A or AAAA
// TODO: what about QCLASS? Maybe we can ignore it as DNSSEC is (I
believe) class independent ...
// TODO: OPCODE == QUERY ? It would not hurt to specify it explicitly.

   c) leftmost label must be one of "kskroll-sentinel-is-ta-<tag-index>.
// TODO: Clarify if it is okay to alter responses if:
- QNAME owner holds CNAME
- RCODE != NOERROR

   If all preconditions are not met, the resolver MUST NOT alter the DNS
response.

3.2 Special processing

   Responses which fullfill all preconditions in section 3.1 are subject
of special processing, depending on leftmost label of the QNAME.

   First, the resolver determines if the numerical value of <tag-index>
equals to keytag of a Root Zone Key Signing Key which is currently
trusted by the local resolver and is stored in its store of trusted keys.

   As second step, the resolver alters response depending on meaning of
the label and presence of key with given keytag among trusted keys. Two
labels and two possible states of the keytag generate four possible
combinations summarized in the table:

                           Keytag trusted
label type |       yes               |       no
--------------------------------------------------------------
is-ta      | return original answer  | return SERVFAIL
not-ta     | return SERVFAIL         | return original answer

// TODO: clear up interaction with caching, CD bit, AD bit, ...

I would be happy to work more on this particular section because I've
already felt pain while implementing this.

Petr Špaček  @  CZ.NIC