Re: [DNSOP] Updated NSEC5 protocol spec and paper

"Paul Hoffman" <> Thu, 09 March 2017 17:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 166FF1296D6 for <>; Thu, 9 Mar 2017 09:31:35 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id JzDjnCR7_DNU for <>; Thu, 9 Mar 2017 09:31:31 -0800 (PST)
Received: from (Opus1.Proper.COM []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 77FAC1296C3 for <>; Thu, 9 Mar 2017 09:31:31 -0800 (PST)
Received: from [] ( []) (authenticated bits=0) by (8.15.2/8.14.9) with ESMTPSA id v29HVPUf005212 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO) for <>; Thu, 9 Mar 2017 10:31:26 -0700 (MST) (envelope-from
X-Authentication-Warning: Host [] claimed to be []
From: Paul Hoffman <>
To: " WG" <>
Date: Thu, 09 Mar 2017 09:31:29 -0800
Message-ID: <>
In-Reply-To: <>
References: <>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <>
Subject: Re: [DNSOP] Updated NSEC5 protocol spec and paper
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: IETF DNSOP WG mailing list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 09 Mar 2017 17:31:35 -0000

On 7 Mar 2017, at 7:29, Shumon Huque wrote:

> We've requested an agenda slot at the DNSOP working group meeting at
> IETF98 to talk about the NSEC5 protocol. Our chairs have requested 
> that
> we send out a note to the group ahead of time, so here it is.
> This protocol has not to our knowledge been presented at dnsop before,
> but has been discussed previously at other IETF venues, such as SAAG.

The protocol described in draft-vcelak-nsec5 has improved since it was 
first presented, but it is still unclear why we should adopt it as part 
of DNSSEC. The benefits listed in the draft are real, but they come at a 
very steep cost for zone administrators who might use NSEC5.

Is there a community of zone admins who want this so much that they 
won't start signing until it exists?

Short of that, is there a community of zone admins who are using 
NSEC/NSEC3 white lies who find this to be a significant improvement?

If not, adopting this seems like a bad idea. No one can operationally 
sign with NSEC5 until nearly all validators have it installed. In the 
meantime, a zone admin who cares about zone enumeration and wants to 
sign will use white lies, and those who don't care about zone 
enumeration won't pay any attention to this.

Even though this document has some really nice design decisions in it, 
should it be adopted in DNSSEC unless it is likely to be deployed?

--Paul Hoffman