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

Petr Špaček <pspacek@isc.org> Fri, 26 November 2021 09:24 UTC

Return-Path: <pspacek@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 B59B63A0C6B for <dnsop@ietfa.amsl.com>; Fri, 26 Nov 2021 01:24:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.949
X-Spam-Level:
X-Spam-Status: No, score=-3.949 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-1.852, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isc.org header.b=VH0SDmvK; dkim=pass (1024-bit key) header.d=isc.org header.b=FZvuL9Yl
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 rVyp-MM4mZpI for <dnsop@ietfa.amsl.com>; Fri, 26 Nov 2021 01:24:53 -0800 (PST)
Received: from mx.pao1.isc.org (mx.pao1.isc.org [149.20.64.53]) (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 AAF713A0C69 for <dnsop@ietf.org>; Fri, 26 Nov 2021 01:24:53 -0800 (PST)
Received: from zimbrang.isc.org (zimbrang.isc.org [149.20.1.12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx.pao1.isc.org (Postfix) with ESMTPS id 162D1433F32 for <dnsop@ietf.org>; Fri, 26 Nov 2021 09:24:52 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=isc.org; s=ostpay; t=1637918692; bh=FNd5gH9YUOUNs6IOZKW8sCYoYIYtft4J6F2R9HzFdeM=; h=Date:Subject:To:References:From:In-Reply-To; b=VH0SDmvKpXbcFOCgx1J5HNkhi3gC1bku9HbZKOiM6SeysOfa3TBGVq2GZaJnPm6lA tTqR93qaj3MpGNSNp3cK6Im98EvTc7RNLG+iyk6LKk2E0xtSAUBPNs8+6xGDOzbj/A og+iyWFpCkV9mmAHt0UwjnliM0jJsVdYq7XDEJkg=
Received: from zimbrang.isc.org (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTPS id E2008F23387 for <dnsop@ietf.org>; Fri, 26 Nov 2021 09:24:51 +0000 (UTC)
Received: from localhost (localhost.localdomain [127.0.0.1]) by zimbrang.isc.org (Postfix) with ESMTP id B078BF23388 for <dnsop@ietf.org>; Fri, 26 Nov 2021 09:24:51 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.10.3 zimbrang.isc.org B078BF23388
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=isc.org; s=05DFB016-56A2-11EB-AEC0-15368D323330; t=1637918691; bh=BGRliqCFfrCee5QRRrbi7pqksDojAb5JihLfVj452Fw=; h=Message-ID:Date:MIME-Version:To:From; b=FZvuL9YlCgGGHdh7ZMZ7e72gp5X9vsxN5X34a/EQustYHO8881HEY0ABPxSmLSIcx vPePgO09TRa3nJU0kXUq+S3Nkuy0Zaj+2gUO3y752tL3P804xD1dsJWTAUiu1D/Ruv fozuuIaoVRZ2lMUMyKSqQZ8bxieRcAIUMWJK7cL4=
Received: from zimbrang.isc.org ([127.0.0.1]) by localhost (zimbrang.isc.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id wuYXdUWqEZzo for <dnsop@ietf.org>; Fri, 26 Nov 2021 09:24:51 +0000 (UTC)
Received: from [192.168.0.157] (ip-86-49-254-49.net.upcbroadband.cz [86.49.254.49]) by zimbrang.isc.org (Postfix) with ESMTPSA id 47345F23387 for <dnsop@ietf.org>; Fri, 26 Nov 2021 09:24:51 +0000 (UTC)
Message-ID: <8f614329-8b75-7c63-7668-e0a45f5b2362@isc.org>
Date: Fri, 26 Nov 2021 10:24:48 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.3.2
Content-Language: en-US
To: dnsop@ietf.org
References: <163777315136.16773.10633006296842101587@ietfa.amsl.com> <yblh7c1fpwf.fsf@w7.hardakers.net> <914ced6b-52c7-9354-4b91-87f80cd26037@pletterpet.nl> <6153c0ed-523a-5225-40ac-5be9fd5e6ed5@isc.org> <92dde682-7b1b-9fa3-f469-cb6623dc5ac4@pletterpet.nl>
From: Petr Špaček <pspacek@isc.org>
In-Reply-To: <92dde682-7b1b-9fa3-f469-cb6623dc5ac4@pletterpet.nl>
Content-Type: text/plain; charset="UTF-8"; format="flowed"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/pPRCYz_4udWZwbfhmWq1L0UBRcE>
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: Fri, 26 Nov 2021 09:24:57 -0000

On 26. 11. 21 9:43, Matthijs Mekking wrote:
> 
> 
> On 25-11-2021 13:00, Petr Špaček wrote:
>> On 25. 11. 21 9:33, Matthijs Mekking wrote:
> 
>>> 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.
>>
>> Honestly I can't see anything more specific which will not get out of 
>> date quickly.
> 
> Can we make use of the keyword MAY? This allows I think for text that 
> will not get out of date:
> 
>     Validating resolvers MAY return an insecure response when processing
>     NSEC3 records with iterations larger than 0. Validating resolvers MAY
>     also return SERVFAIL when processing NSEC3 records with iterations
>     larger than 0. This significantly decreases the requirements
>     originally specified in Section 10.3 of [RFC5155]. See the Security
>     Considerations for arguments on how to handle responses with non-zero
>     iteration count.
> 
> Having text that says "MAY do this at value X" is more quantifiable and 
> IMO a stronger signal that zone publishers really should not use value X.

Yes, I like this!

Maybe your proposed text can be prepended/appended to the current 
content of 3.2.  Recommendation for validating resolvers, so we can keep 
the "vendors are encouraged to continue evaluating NSEC3 iteration count 
deployments" part?

-- 
Petr Špaček