IETF Logo Mail Archive

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

Wes Hardaker <wjhns1@hardakers.net> Fri, 25 February 2022 23:30 UTC

Return-Path: <wjhns1@hardakers.net>
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 13C323A091E for <dnsop@ietfa.amsl.com>; Fri, 25 Feb 2022 15:30:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, 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 oE9EXu76kgom for <dnsop@ietfa.amsl.com>; Fri, 25 Feb 2022 15:30:24 -0800 (PST)
Received: from mail.hardakers.net (mail.hardakers.net [168.150.192.181]) (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 673063A0913 for <dnsop@ietf.org>; Fri, 25 Feb 2022 15:30:24 -0800 (PST)
Received: from localhost (unknown [10.0.0.3]) by mail.hardakers.net (Postfix) with ESMTPA id 3DACC246D5; Fri, 25 Feb 2022 15:30:23 -0800 (PST)
From: Wes Hardaker <wjhns1@hardakers.net>
To: Vladimír Čunát <vladimir.cunat+ietf@nic.cz>
Cc: dnsop@ietf.org, Wes Hardaker <wjhns1@hardakers.net>
References: <163777315136.16773.10633006296842101587@ietfa.amsl.com> <4e4527b6-b0b3-33f3-3849-8a593fe29a1d@nic.cz> <ybly22j7m5m.fsf@w7.hardakers.net> <95a4103b-dd26-17ba-d4dd-ac82b2bd510f@nic.cz>
Date: Fri, 25 Feb 2022 15:30:23 -0800
In-Reply-To: <95a4103b-dd26-17ba-d4dd-ac82b2bd510f@nic.cz> ("Vladimír Čunát"'s message of "Tue, 22 Feb 2022 12:29:21 +0100")
Message-ID: <yblh78m34og.fsf@w7.hardakers.net>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fnFmnhtWENw8ZsAta6xB97EmpAg>
Subject: Re: [DNSOP] I-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, 25 Feb 2022 23:30:29 -0000

Vladimír Čunát <vladimir.cunat+ietf@nic.cz> writes:

> On 09/02/2022 22.41, Wes Hardaker wrote:
> 
>     So I've re-arranged things a bit to hopefully address the flow better.
>     Let em know if you think further improvements are warranted.
>     
> I'd still probably suggest at least a minimalist change like:
> -Note that a validating resolver MUST still validate the signature
> +Note that a validating resolver returning an insecure response MUST still validate the
> signature
> 
> But to me it's certainly not a big deal.  (Though not changing this would mean that
> formally I wouldn't be exactly following the RFC.)

I think there seems to be consensus about this, so I implemented your
change.

I think it's actually best to be as clear as possible as what's
acceptable.  IE, you shouldn't be trying to find hidden loopholes.  So I
added this:

Validating resolvers MAY choose to not respond to NSEC3 records with
iterations larger than 0.

-- 
Wes Hardaker
USC/ISI

v2.31.3 | Report a Bug | By Email | System Status