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

Petr Špaček <> Wed, 21 February 2018 14:54 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 25B7D1270AB for <>; Wed, 21 Feb 2018 06:54:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id zEDpOxzJj26i for <>; Wed, 21 Feb 2018 06:54:49 -0800 (PST)
Received: from ( [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D0F58126DFB for <>; Wed, 21 Feb 2018 06:54:48 -0800 (PST)
Received: from [IPv6:2001:1488:fffe:6:e8c1:e0ff:fefd:713] (unknown [IPv6:2001:1488:fffe:6:e8c1:e0ff:fefd:713]) by (Postfix) with ESMTPSA id 2D1386256D; Wed, 21 Feb 2018 15:54:47 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1519224887; bh=ujvUcyTWXLTQzf3csm8L5DpzOpNvjIKmn7cbtfsOkig=; h=To:From:Date; b=a01Drh+Z+KtKOcyKy6ZBNGtTteS2O98gLRHAtvVqfHWoE52O6ZFtBZGyiOgMtI0+h a1beU+9wGxh4CUEFpu88aV9gUkmP/lr+81V6k+gPiyhVf45ha9VvKHUlYWk2QogqJC Iudes5csDgKKUIT0E8mFtMbJEqlFoMWyrYktSiow=
To:, Warren Kumari <>
References: <>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <>
Organization: CZ.NIC
Message-ID: <>
Date: Wed, 21 Feb 2018 15:54:46 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-kskroll-sentinel-02.txt
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 21 Feb 2018 14:54:52 -0000

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.

(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

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

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

On 21.2.2018 15:03, wrote:
> 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-
> .
>    [ This document is being collaborated on in Github at:
>  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:
> There are also htmlized versions available at:
> A diff from the previous version is available at: