Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel

Ondřej Surý <ondrej@isc.org> Tue, 24 April 2018 13:02 UTC

Return-Path: <ondrej@isc.org>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CFAF127AD4 for <dnsop@ietfa.amsl.com>; Tue, 24 Apr 2018 06:02:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.921
X-Spam-Level:
X-Spam-Status: No, score=-5.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FROM_EXCESS_BASE64=0.979, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YzL52uhsA96p for <dnsop@ietfa.amsl.com>; Tue, 24 Apr 2018 06:02:37 -0700 (PDT)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [IPv6:2001:4f8:0:2::2b]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EFEC126C19 for <dnsop@ietf.org>; Tue, 24 Apr 2018 06:02:27 -0700 (PDT)
Received: from zmx1.isc.org (zmx1.isc.org [149.20.0.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.pao1.isc.org (Postfix) with ESMTPS id B6B8B3AB03B; Tue, 24 Apr 2018 13:02:26 +0000 (UTC)
Received: from zmx1.isc.org (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTPS id 844D8160053; Tue, 24 Apr 2018 13:02:26 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1]) by zmx1.isc.org (Postfix) with ESMTP id 74EE016006B; Tue, 24 Apr 2018 13:02:26 +0000 (UTC)
Received: from zmx1.isc.org ([127.0.0.1]) by localhost (zmx1.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id XbmYKn4PdK6g; Tue, 24 Apr 2018 13:02:26 +0000 (UTC)
Received: from [10.10.0.193] (40.20.broadband5.iol.cz [88.100.20.40]) by zmx1.isc.org (Postfix) with ESMTPSA id 9499F160053; Tue, 24 Apr 2018 13:02:25 +0000 (UTC)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.3 \(3445.6.18\))
From: =?utf-8?B?T25kxZllaiBTdXLDvQ==?= <ondrej@isc.org>
In-Reply-To: <20180407062714.GA63728@isc.org>
Date: Tue, 24 Apr 2018 15:02:22 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <09F25B8D-25CA-47C4-B1A1-DA56B86D68F8@isc.org>
References: <CADyWQ+EE9YCCM03wKvd-HefpoQVqhOfeeLKLV8L2LJj+tqmEzA@mail.gmail.com> <CACWOCC936z-4j8e+d7bvhfr_Mk8tk64tkuiRDTRtrqrBTJBKJw@mail.gmail.com> <CAHw9_iLgTvPHe5jeL-0QZJ4+cxes8bBpCEULuDKThpjXoKzrbA@mail.gmail.com> <20180406134501.GC49550@vurt.meerval.net> <4A943DE7-81BC-41AC-93F7-4EC0975DF6B6@gmail.com> <CAHw9_iLTJUdTt_YnuC+sw2aNB10iGZ4bbcmOnf4i-y5Zssu0qw@mail.gmail.com> <20180407062714.GA63728@isc.org>
To: dnsop <dnsop@ietf.org>
X-Mailer: Apple Mail (2.3445.6.18)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/rocNJ7beiRPQkAMwxCFyQi6D1gg>
Subject: Re: [DNSOP] Working Group Last Call for: draft-ietf-dnsop-kskroll-sentinel
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: Tue, 24 Apr 2018 13:02:39 -0000

And the MR was peer-review and merged into BIND master branch with intent to backport the feature into older release branches.

I don’t think it’s a useful or helpful to change the rules for existing adopted work.  We need to have a discussion on the mechanisms that would allow implementors to know when to start the implementation of existing draft. From implementors point, it makes little sense to start implementing before the protocol change is almost fully baked (aka WGLC and further), because until then the protocol might change considerably.

So, if we require implementation report further down the road, it needs to be more clearly defined than people suddenly shouting “this is not ready” when WGLC starts.  And while the attempt to implement something is certainly useful to get valuable feedback, it also imposes some costs (with undefined limit) on implementors (especially the open source implementors) and it sort of discards the whole “Proposed Standard” -> “Internet Standard” classification at global IETF level.

I get that we probably need something more lightweight than “Internet Standard” at the WG level, but this needs to be discussed and consensus reached.

ISC gave our feedback during the implementation and here are some nits from me (re-reading the document again):

~~~

Section "2.  Protocol Walkthrough Example" will be made into Appendix at publication time, so just reminder here that you also need to change the references like "(see the logic below)” when you move the section - perhaps add direct reference to the other section this refers to?

~~~

The table in 3.2 says:

"Key Tag is trusted” and “Key Tag is not trusted” - it seems little bit confusing to me; I think that “Key is trusted” and “Key is not trusted”; or some change similar to this needs to be made:

“First, the resolver determines if the Key Tag is trusted by comparing numerical value of <key-tag>
   to any of the Key Tags of an active root zone KSK which is
   currently trusted…"

in paragraph just before the table you mix “Key Tag” and “keytag” and there’s also <key-tag>…

My understanding of the text and the proposed fix:

[…]

   First, the resolver determines if the numerical value of <key-tag> is
   equal to any of the Key Tags of an active root zone KSK which is
   currently trusted by the local resolver and is stored in its store of
   trusted keys.  If a match is found the <key-tag> is trusted. An active
   root zone KSK is one which could currently be used for
   validation (that is, a key that is not in either the AddPend or
   Revoked state as described in [RFC5011]).  

   Second, the resolver alters the response being sent to the original
   query based on both the left-most label and the presence of a key
   with given Key Tag in the trust anchor store.  Two labels and two
   possible states of the <key-tag> generate four possible combinations
   summarized in the table:

    Label      |   <key-tag> is trusted    |   <key-tag> is not trusted
    ------------------------------------------------------------------
    is-ta      | return original answer  | return SERVFAIL
    not-ta     | return SERVFAIL         | return original answer

[…]

~~~

   o  A query name that is signed with a DNSSEC signature that cannot be
      validated (such as if the corresponding RRset is not signed with a
      valid RRSIG record).

This is called “Bogus” by RFC 4033 Section 5 -> maybe a reference?

~~~

In  Section: 7.  Privacy Considerations

s/mechansim/mechanism/

~~~

That is all folks.

Cheers,
Ondrej
--
Ondřej Surý
ondrej@isc.org

> On 7 Apr 2018, at 08:27, Evan Hunt <each@isc.org> wrote:
> 
> On Fri, Apr 06, 2018 at 10:09:50PM -0400, Warren Kumari wrote:
>> I think I heard that ISC was considering adding support, but was
>> planning on waiting till RFC / some sort of LC.
> 
> Yes. The work in progress is available here:
> https://gitlab.isc.org/isc-projects/bind9/merge_requests/123
> 
> -- 
> Evan Hunt -- each@isc.org
> Internet Systems Consortium, Inc.
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop