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

Vladimír Čunát <> Tue, 22 February 2022 22:56 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 662143A0997 for <>; Tue, 22 Feb 2022 14:56:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.812
X-Spam-Status: No, score=-2.812 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, HTML_MESSAGE=0.001, NICE_REPLY_A=-0.714, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id egK-Rt9MbO_c for <>; Tue, 22 Feb 2022 14:56:35 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B51EE3A09A1 for <>; Tue, 22 Feb 2022 14:56:33 -0800 (PST)
Received: from [IPV6:2001:1488:fffe:6:48f:1795:438c:5e26] (unknown [IPv6:2001:1488:fffe:6:48f:1795:438c:5e26]) by (Postfix) with ESMTPSA id DF7FD13FFE5; Tue, 22 Feb 2022 23:56:30 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;; s=default; t=1645570591; bh=frzFxaNQnH9Atk+Hp6AQnWlLMlUyoDAJnbTXlM5CqmM=; h=Date:To:From; b=WlD0VOJ3XfoyvvPq6Y3fP6Mw3qD5LeUprnd4VZgGnjmzsPZZYb4cvgkIdljhQYjfZ cww0eDz7IcbtMQWXJrQL36IEdEZE/Jgdqi1NHHw3R+gVq623ruorJ1eUeirhtvHS8p Ux1x9qlQqQZuA5Imq6OdBGhA9hQHMX0BTNb8AHpY=
Content-Type: multipart/alternative; boundary="------------HFQHYMmiJ7shA202qv7HXYhC"
Message-ID: <>
Date: Tue, 22 Feb 2022 23:56:30 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.1
Content-Language: en-US
To: "" <>
Cc: Wes Hardaker <>, Geoff Huston <>
References: <> <> <> <> <>
From: Vladimír Čunát <>
In-Reply-To: <>
X-Virus-Scanned: clamav-milter 0.102.4 at mail
X-Virus-Status: Clean
Archived-At: <>
Subject: Re: [DNSOP] I-D Action: draft-ietf-dnsop-nsec3-guidance-02.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Feb 2022 22:56:41 -0000

On 22/02/2022 20.02, Geoff Huston wrote:
> I’m not sure I follow that latter comment relating to "a validating resolver returning an insecure response" - Do you mean:
> a) - a DNSSEC-validation capable resolver responding to a query that had the CD bit set?
> b) - a DNSSEC-validation capable resolver responding to a query that had no EDNS(0) extensions at all?
> c) - a DNSSEC-validation capable resolver responding to a query that received an NSEC record signed with an algorithm, that was not recognised by the resolver?

Oh, I'm sorry, I thought it would be perfectly clear in the context of 
this previous e-mails in this thread and the draft's paragraphs directly 
preceding the diff I posted.

Anyway, let me explain why our current code would violate the text but 
not the intent (or security properties).  It's about the "may SERVFAIL" 
case, defined as
 > Validating resolvers MAY also return SERVFAIL when processing NSEC3 
records with iterations larger than 0.

I believe that the cleanest and least bug-prone way to implement this 
sub-case is to simply ignore any NSEC3 records with iterations over the 
limit.  You do not need to check any kind of signatures or any further 
properties, as it's just trading one SERVFAIL for another SERVFAIL.  
(OK, maybe the EDE code or similar diagnostics could suffer a little, 
but I'm not convinced the complications are worth it.)  Now, this 
implementation approach would get into conflict with that sentence:
 > Note that a validating resolver MUST still validate the signature

so I was trying to suggest a simple way of patch it up to avoid 
colliding with the implementation approach that I find useful.  I don't 
really care about particular formulation, but I'd find it a bit 
unfortunate if I had to choose between not strictly following the RFC or 
complicating the implementation (unnecessarily in my view).

I hope I've stated my argument clearly now.  Thanks for bearing with me.