Re: [DNSOP] Updated NSEC5 protocol spec and paper

Dave Lawrence <> Fri, 10 March 2017 20:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4A1821294DA for <>; Fri, 10 Mar 2017 12:38:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id M99uIf0OAMPB for <>; Fri, 10 Mar 2017 12:38:53 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E6791294D0 for <>; Fri, 10 Mar 2017 12:38:53 -0800 (PST)
Received: by (Postfix, from userid 102) id 0EBE03F469; Fri, 10 Mar 2017 15:38:52 -0500 (EST)
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Message-ID: <>
Date: Fri, 10 Mar 2017 15:38:51 -0500
From: Dave Lawrence <>
To: " WG" <>
In-Reply-To: <>
References: <> <>
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: Fri, 10 Mar 2017 20:38:55 -0000

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

I think that question is a little extreme and need not go that far to
determine whether something is worthwhile to pursue.

My interest in NSEC5 is largely around the significant performance
gains it has over NSEC3-WhiteLies, with double the throughout reported
in "Can NSEC5 be Practical for DNSSEC Deployments"

We have a large number of zones that are not yet signed, and a
non-trivial part of that is because of performance.  NSEC5 has an
impact in addressing that issue.

Professionally, I'm somewhat less concerned about the enumeration
issue because the at least some of the zones where I want to use it
have highly structured names anyway.  Enumerating them is trivial even
in plain old non-DNSSEC DNS.  In the other, less-structured zones that
we already sign we use classic NSEC3 and are considering going to
NSEC3-WL on behalf of customers that do care about it. We have online
ksks for other features required of these zones.

On a personal level I appreciate that this proposal enhances ksk
security while addressing the enumeration problem.