Re: [DNSOP] Updated NSEC5 protocol spec and paper

"Paul Hoffman" <paul.hoffman@vpnc.org> Fri, 10 March 2017 23:44 UTC

Return-Path: <paul.hoffman@vpnc.org>
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 8B0C31294AE for <dnsop@ietfa.amsl.com>; Fri, 10 Mar 2017 15:44:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] 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 r4ug_cH5ClZI for <dnsop@ietfa.amsl.com>; Fri, 10 Mar 2017 15:44:19 -0800 (PST)
Received: from mail.proper.com (Opus1.Proper.COM [207.182.41.91]) (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 EBC8A129495 for <dnsop@ietf.org>; Fri, 10 Mar 2017 15:44:18 -0800 (PST)
Received: from [10.32.60.87] (142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176]) (authenticated bits=0) by mail.proper.com (8.15.2/8.14.9) with ESMTPSA id v2ANiAmJ062904 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 10 Mar 2017 16:44:12 -0700 (MST) (envelope-from paul.hoffman@vpnc.org)
X-Authentication-Warning: mail.proper.com: Host 142-254-101-176.dsl.dynamic.fusionbroadband.com [142.254.101.176] claimed to be [10.32.60.87]
From: Paul Hoffman <paul.hoffman@vpnc.org>
To: Dave Lawrence <tale@dd.org>
Date: Fri, 10 Mar 2017 15:44:14 -0800
Message-ID: <16ECA0DA-92AE-401E-B3F6-ED82CE7E03F7@vpnc.org>
In-Reply-To: <22723.3803.952649.43175@gro.dd.org>
References: <CAHPuVdXTcSaVcN6fBbPy3e=PgRvg8=GemSN_YFhzX387x8YW-A@mail.gmail.com> <CFBF172D-FDD7-4DE1-B5C5-7C76A7792549@vpnc.org> <22723.3803.952649.43175@gro.dd.org>
MIME-Version: 1.0
Content-Type: text/plain; format="flowed"
X-Mailer: MailMate (1.9.6r5347)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/iVobwDz2qAO9HkMVM7SE44JIF0Q>
Cc: "dnsop@ietf.org WG" <dnsop@ietf.org>
Subject: Re: [DNSOP] Updated NSEC5 protocol spec and paper
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.17
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, 10 Mar 2017 23:44:20 -0000

On 10 Mar 2017, at 12:38, Dave Lawrence wrote:

> 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.

Fully agree. That's why I followed it with:

>> 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?

> 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"
> <https://eprint.iacr.org/2017/099.pdf>.

I found the paper intriguing, but possibly confusing. My reading is that 
it compares an optimized server using NSEC5 against an unoptimized 
server using NSEC3 White Lies. If my reading is correct, a better 
comparison would be if they added a reasonably-efficient NSEC3 White 
Lies feature to their server for comparison. If my reading is wrong, 
then great, 2x for negative answers seems like a good speedup.

> 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.

Thanks, this makes me hopeful if the 2x performance number holds up.

--Paul Hoffman