Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse

Matthijs Mekking <matthijs@pletterpet.nl> Tue, 26 April 2016 08:11 UTC

Return-Path: <matthijs@pletterpet.nl>
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 EE55612D0D3 for <dnsop@ietfa.amsl.com>; Tue, 26 Apr 2016 01:11:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.9
X-Spam-Level:
X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 L8RC9MyIkfUv for <dnsop@ietfa.amsl.com>; Tue, 26 Apr 2016 01:11:20 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 57D8F12D0FB for <dnsop@ietf.org>; Tue, 26 Apr 2016 01:11:18 -0700 (PDT)
Received: by dicht.nlnetlabs.nl (Postfix, from userid 58) id 9B7CE4954; Tue, 26 Apr 2016 10:11:16 +0200 (CEST)
Received: from [IPv6:2001:981:19be:1:d401:d66:a6a3:9b9d] (unknown [IPv6:2001:981:19be:1:d401:d66:a6a3:9b9d]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id CAA304950 for <dnsop@ietf.org>; Tue, 26 Apr 2016 10:11:14 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
To: dnsop@ietf.org
References: <6f6a767c-a204-de3c-7111-af0cdb615ec6@gmail.com> <e6df589c-13ad-7e8f-843a-dec8f9c62c55@gmail.com>
From: Matthijs Mekking <matthijs@pletterpet.nl>
X-Enigmail-Draft-Status: N1110
Message-ID: <571F22A1.9020101@pletterpet.nl>
Date: Tue, 26 Apr 2016 10:11:13 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0
MIME-Version: 1.0
In-Reply-To: <e6df589c-13ad-7e8f-843a-dec8f9c62c55@gmail.com>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 7bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/PsmDivV8IMWtUlQ9YjV-ffpOsKM>
Subject: Re: [DNSOP] Call for Adoption for draft-fujiwara-dnsop-nsec-aggressiveuse
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 26 Apr 2016 08:11:27 -0000

Late to the party, but FWIW: I also support adoption and am willing to
discuss and review this work.

Some comments:

- Section 4.1 relaxes the restriction for resolvers from RFC 4035 to MAY
do aggressive NSEC/NSEC3 usage, while section 4.2 says that a resolver
SHOULD support aggressive NSEC usage and enable it by default. This to
me seems inconsistent use of the key words.

- In section 4.3 I suggest to replace the second paragraph with:

   If the full-service resolver's cache contains an NSEC3 matching
   the closest encloser, an NSEC3 covering the next closer name, and
   an NSEC3 covering the source of synthesis, it is possible for the
   full-service resolver to respond with NXDOMAIN immediately.

Also, what exactly defines a full-service resolver? I think we care
about caching and validating only here.

- Section 4.3 suggests to build a separate cache of NSEC and NSEC3
resource records for each signer domain name. This to me seems like an
implementation detail and is not necessarily required. In fact, a zone
may switch from NSEC to NSEC3 and vice versa, so you will need to check
them both if you implement it as a separate cache.

- I don't see why setting the CD bit is an indication that NSEC(3)
aggressive usage should not be used. Could you elaborate on that?

- My body shivers when reading that resolvers MAY use NSEC(3) records in
a NXDOMAIN response without validating them. Luckily the draft already
highly recommends that it should do validation. I would like to make it
even stronger and remove the MAY key word here, and perhaps use the
formal key word SHOULD do validation.


Best regards,
  Matthijs

On 04/26/2016 12:33 AM, Tim Wicinski wrote:
> All
> 
> The Call for Adoption has passed and there seems to be strong consensus
> to adopt it. Thanks everyone who has signed up to offer review comments,
> etc.
> 
> A new version will be uploaded soon by the authors once they incorporate
> the comments made during the Call for Adoption.
> 
> thanks
> tim
> 
> 
> On 4/10/16 10:18 AM, Tim Wicinski wrote:
>> This was discussed in Buenos Aires Friday morning, but the sense we
>> received from the room is that the group should move forward with this
>> draft.  While we like the simplicity of Warren and Geoff's cheese-shop
>> draft (draft-wkumari-dnsop-cheese-shop), it is basically a simple
>> proof-of-concept.    The suggestion was to document the cheese-shop idea
>> in this draft.
>>
>> This starts a Call for Adoption for Aggressive use of NSEC/NSEC3
>> draft-fujiwara-dnsop-nsec-aggressiveuse
>>
>> The draft is available here:
>>
>> https://datatracker.ietf.org/doc/draft-fujiwara-dnsop-nsec-aggressiveuse/
>>
>> Please review this draft to see if you think it is suitable for adoption
>> by DNSOP, and comments to the list, clearly stating your view.  *Speak
>> Up* if you have strong opposition to this work.
>>
>> *More Importantly*
>> Please also indicate if you are willing to contribute text, review, etc.
>> We will want several dedicated reviewers on this.
>>
>> I'm going to make this a short call for adoption, as we've discussed
>> this in a few meetings.
>>
>> This call for adoption ends 17 April 2016.
>>
>> Thanks,
>> tim wicinski
>> DNSOP co-chair
> 
> _______________________________________________
> DNSOP mailing list
> DNSOP@ietf.org
> https://www.ietf.org/mailman/listinfo/dnsop