Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt

Matthijs Mekking <matthijs@pletterpet.nl> Thu, 25 November 2021 08:33 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 B7AD43A1010 for <dnsop@ietfa.amsl.com>; Thu, 25 Nov 2021 00:33:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.747
X-Spam-Level:
X-Spam-Status: No, score=-3.747 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_NONE=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 SqG11MRSWxLT for <dnsop@ietfa.amsl.com>; Thu, 25 Nov 2021 00:33:15 -0800 (PST)
Received: from lb1-smtp-cloud8.xs4all.net (lb1-smtp-cloud8.xs4all.net [194.109.24.21]) (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 1CAD83A100F for <dnsop@ietf.org>; Thu, 25 Nov 2021 00:33:13 -0800 (PST)
Received: from cust-69fe625f ([IPv6:fc0c:c103:c4a6:cf3c:d2f9:56fe:3f93:cb0b]) by smtp-cloud8.xs4all.net with ESMTPSA id qABpmqdSOBB1QqABqmsHvy; Thu, 25 Nov 2021 09:33:11 +0100
To: dnsop@ietf.org
References: <163777315136.16773.10633006296842101587@ietfa.amsl.com> <yblh7c1fpwf.fsf@w7.hardakers.net>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <914ced6b-52c7-9354-4b91-87f80cd26037@pletterpet.nl>
Date: Thu, 25 Nov 2021 09:33:09 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0
MIME-Version: 1.0
In-Reply-To: <yblh7c1fpwf.fsf@w7.hardakers.net>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4xfFw+VVWYXlagJbLQoWRK5s0Gc3jKeelXg90mAo3hGQXtmWVL0DyCbfE7Koo2j+MQBxXnX5PKLnIDcmAHnx2AW2o8OtMZ5U+XOTdmkY0uYi6J2Rsd962Z PdexpeLu24aFS2kBTbwUsAECga0dzwgPDjS1pYWyfwHvcLXL2KXVCl3F3MFVpq5fawNIWkuxHRKk+jIfPexVcNESXBgigT8mIH8K6dSD9d0UuChXNm0J9+zT tlEpSFg0BJoLkcwenLUmrLt+BT1qiyHCs5sFQ9u94Z8=
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jAP1WWrxJTMq9HgNXgWFc-Sqj_A>
Subject: Re: [DNSOP] DNSOPI-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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: Thu, 25 Nov 2021 08:33:20 -0000

Hi Wes,

I think the changes are moving the document in the right direction.

Some comments:


3.1.  Best-practice for zone publishers

I wonder if we can make the requirement even stronger by saying "If 
NSEC3 must be used, then an iterations count of 0 MUST be used to 
alleviate computational burdens." (MUST instead of SHOULD).

Or is there a valid reason for zone publishers to set iterations to a 
non-zero value?


3.2.  Recommendation for validating resolvers

I understand why the new text is here, but I think this now actually 
gives too little advice for operators and vendors.

I know, this is a vague comment, I need to think about it a bit more.


3.2.  Recommendation for validating resolvers

    Validating resolvers returning an insecure or SERVFAIL answer because
    of unsupported NSEC parameter values SHOULD return an Extended DNS
    Error (EDE) EDNS0 option of value.

I believe this should be NSEC3 parameter values here (instead of NSEC).


4.  Security Considerations

I appreciate that you added the reasoning for lowering the acceptable 
iteration counts here and in section 3.2 but I miss the argument for not 
lowering. Suggested text:

    On the other hand, zones that are still using high iteration counts
    may become unreachable on some parts of the network when a resolver
    decides to return SERVFAIL above a higher point. Before lowering the
    acceptable iteration count, resolver operators and resolver software
    vendors are encouraged to monitor the used iteration counts and reach
    out to zone publishers to implement this document by setting the
    iteration count to 0.


Appendix E.  Implementation Notes

Note that BIND 9.16.16 and up will treat DNSSEC responses containing 
NSEC3 records with iteration counts greater than 150 are now treated as 
insecure, and the maximum supported number of NSEC3 iterations that can 
be configured for a zone has been reduced to 150.


Best regards,

Matthijs


On 24-11-2021 18:02, Wes Hardaker wrote:
> internet-drafts@ietf.org writes:
> 
>>          Title           : Guidance for NSEC3 parameter settings
>>          Authors         : Wes Hardaker
>>                            Viktor Dukhovni
>> 	Filename        : draft-ietf-dnsop-nsec3-guidance-02.txt
>> 	Pages           : 10
>> 	Date            : 2021-11-24
> 
> This version attempts to take into account the discussion from the WG
> meeting at IETF 112.  Concrete text proposals appreciated so we can
> finish this work and publish it.
>