Re: [DNSOP] Updated NSEC5 protocol spec and paper

"Woodworth, John R" <> Fri, 10 March 2017 15:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7902129492 for <>; Fri, 10 Mar 2017 07:16:14 -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, RCVD_IN_DNSWL_NONE=-0.0001, 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 H5vh7LDo46aB for <>; Fri, 10 Mar 2017 07:16:13 -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 55D4F129485 for <>; Fri, 10 Mar 2017 07:16:13 -0800 (PST)
Received: from ( []) by (8.14.8/8.14.8) with ESMTP id v2AFGBEt054456 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 10 Mar 2017 09:16:12 -0600
Received: from (unknown []) by IMSA (Postfix) with ESMTP id AE2601E007B; Fri, 10 Mar 2017 09:16:06 -0600 (CST)
Received: from lxomp06u.corp.intranet (unknown []) by (Postfix) with ESMTP id 8F1111E0075; Fri, 10 Mar 2017 09:16:06 -0600 (CST)
Received: from lxomp06u.corp.intranet (localhost []) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v2AFG6No020351; Fri, 10 Mar 2017 09:16:06 -0600
Received: from vodcwhubex501.ctl.intranet (vodcwhubex501.ctl.intranet []) by lxomp06u.corp.intranet (8.14.8/8.14.8) with ESMTP id v2AFG60i020346 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 10 Mar 2017 09:16:06 -0600
Received: from PODCWMBXEX501.ctl.intranet ([]) by vodcwhubex501.ctl.intranet ([]) with mapi id 14.03.0339.000; Fri, 10 Mar 2017 09:16:06 -0600
From: "Woodworth, John R" <>
To: 'Paul Hoffman' <>, " WG" <>
Thread-Topic: [DNSOP] Updated NSEC5 protocol spec and paper
Thread-Index: AQHSl1moYAUwcrq0jE+qV/1Y/Ued86GNK9qAgAB810A=
Date: Fri, 10 Mar 2017 15:16:05 +0000
Message-ID: <A05B583C828C614EBAD1DA920D92866BD06F4468@PODCWMBXEX501.ctl.intranet>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-TM-AS-MML: disable
X-CFilter-Loop: Reflected
Archived-At: <>
Cc: 'JW' <>, "Woodworth, John R" <>, "Ballew, Dean" <>
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 15:16:14 -0000

> -----Original Message-----
> From: DNSOP [] On Behalf Of Paul Hoffman
> 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.

Hi Paul,

Apologies, I am somewhat new to this draft (and admittedly to the
process) but what I read was a very elegant solution to this steep
cost.  The authors seem to have gone through great pains to bridge
this period of incompatibility.

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

With the draft's aliasing of algorithms, why couldn't (wouldn't) a zone
at least experimenting with this be able to provide 2 sets of keys,
one pre-NSEC5 and the other NSEC5 and forward?

I might be missing something here but I think I may actually love the
simplicity of it and it seems to be at least a viable bridge to NSEC5
as part of the future.  This seems to be a great use of what RFC-4035
and RFC-6840 hint at regarding multiple keys/ multiple signatures.

Best regards,

> 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
> _______________________________________________
> DNSOP mailing list

This communication is the property of CenturyLink and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments.