Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.

Matt Larson <mlarson@verisign.com> Mon, 22 February 2010 16:16 UTC

Return-Path: <mlarson@verisign.com>
X-Original-To: dnsop@core3.amsl.com
Delivered-To: dnsop@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AD623A7B18 for <dnsop@core3.amsl.com>; Mon, 22 Feb 2010 08:16:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.593
X-Spam-Level:
X-Spam-Status: No, score=-9.593 tagged_above=-999 required=5 tests=[AWL=1.006, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEG-tQA7K7mH for <dnsop@core3.amsl.com>; Mon, 22 Feb 2010 08:16:01 -0800 (PST)
Received: from cliffie.verisignlabs.com (mail.verisignlabs.com [65.201.175.9]) by core3.amsl.com (Postfix) with ESMTP id 74E583A6FF9 for <dnsop@ietf.org>; Mon, 22 Feb 2010 08:16:01 -0800 (PST)
Received: from monsoon.verisignlabs.com (scooter.bo.labs.vrsn.com [172.25.170.10]) by cliffie.verisignlabs.com (Postfix) with ESMTP id 9A25E18CA7 for <dnsop@ietf.org>; Mon, 22 Feb 2010 11:17:59 -0500 (EST)
Received: from dul1mcmlarson-l1-2.local (dul1mcmlarson-l1.labs.vrsn.com [10.131.244.26]) by monsoon.verisignlabs.com (Postfix) with ESMTP id 95761242168 for <dnsop@ietf.org>; Mon, 22 Feb 2010 11:17:59 -0500 (EST)
Date: Mon, 22 Feb 2010 11:17:59 -0500
From: Matt Larson <mlarson@verisign.com>
To: dnsop WG <dnsop@ietf.org>
Message-ID: <20100222161758.GF2228@dul1mcmlarson-l1-2.local>
References: <1AEAE091-2EB3-41DC-A51B-8DD49C10FAD5@NLnetLabs.nl> <24C8A8E2A81760E31D4CDE4A@Ximines.local> <8E6C64ED-A336-4E8B-996F-9FB471EB07C6@NLnetLabs.nl> <4B7FE58C.5030605@ogud.com> <20100220202751.GB54720@shinkuro.com> <20100220213133.GE2477@isc.org> <4B807DC0.9050807@ogud.com> <315AD36E-879A-4512-A6A8-B64372E3D3CF@sinodun.com> <201002220022.o1M0M3qR048760@drugs.dv.isc.org> <d3aa5d01002212013x50993902xa8be099c09aefd16@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
In-Reply-To: <d3aa5d01002212013x50993902xa8be099c09aefd16@mail.gmail.com>
User-Agent: Mutt/1.5.18 (2008-05-17)
Subject: Re: [DNSOP] rfc4641bis: NSEC vs NSEC3.
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Mon, 22 Feb 2010 16:16:02 -0000

On Sun, 21 Feb 2010, Eric Rescorla wrote:
> On Sun, Feb 21, 2010 at 4:22 PM, Mark Andrews <marka@isc.org> wrote:
> > Actually NSEC is technically better at proving non-existance.  NSEC3
> > has a non zero false positive rate due to the fact that the names
> > are hashed.  NSEC has a zero false positive rate.
> >
> > This is not to say the false positive rate is high enough to stop
> > using NSEC3, but that it needs to be acknowledged.
> 
> Unless I'm misreading the specifications, unless you're using an extremely
> poor or short hash function, the probability of false positive is vanishingly
> small (order 2^{-100}). This shouldn't be acknowledged, but rather
> should be ignored. Moreover, it appears that NSEC3 has a mechanism
> for dealing with it in S C.2.1 (pointless, IMO...)
> 
> So, I don't see what the issue is.

+1, total and complete agreement.  I am adamantly opposed to including
any text about SHA1 hash collisions in an NSEC3 context.

Matt