Re: [DNSOP] Comments regarding the NSEC5

Nicholas Weaver <nweaver@icsi.berkeley.edu> Wed, 11 March 2015 16:53 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B70491A1A70 for <dnsop@ietfa.amsl.com>; Wed, 11 Mar 2015 09:53:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.288
X-Spam-Level:
X-Spam-Status: No, score=0.288 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=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 9-VWWGdd7UVb for <dnsop@ietfa.amsl.com>; Wed, 11 Mar 2015 09:53:08 -0700 (PDT)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) by ietfa.amsl.com (Postfix) with ESMTP id 881661A1B60 for <dnsop@ietf.org>; Wed, 11 Mar 2015 09:52:56 -0700 (PDT)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 824DE2C4039; Wed, 11 Mar 2015 09:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at ICSI.Berkeley.EDU
Received: from rock.ICSI.Berkeley.EDU ([127.0.0.1]) by localhost (maihub.ICSI.Berkeley.EDU [127.0.0.1]) (amavisd-new, port 10024) with LMTP id JEb3FQDWnAD2; Wed, 11 Mar 2015 09:52:56 -0700 (PDT)
Received: from gala.icir.org (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 1BC4D2C4032; Wed, 11 Mar 2015 09:52:56 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_1564CAD6-AC88-4B05-BEEA-BC4E3887FA0C"; protocol="application/pgp-signature"; micalg="pgp-sha512"
X-Pgp-Agent: GPGMail 2.5b5
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <55006FC7.1030206@nic.cz>
Date: Wed, 11 Mar 2015 09:52:55 -0700
Message-Id: <17FB96B6-B44C-4C9B-A68E-112C5EAE0CA3@icsi.berkeley.edu>
References: <55002098.5060709@redhat.com> <55006AF8.4090500@nic.cz> <55006D98.7000300@redhat.com> <55006FC7.1030206@nic.cz>
To: Jan Včelák <jan.vcelak@nic.cz>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/byb8Ots7i_vEJw-Trr5nVvxW7Uo>
Cc: Florian Weimer <fweimer@redhat.com>, dnsop@ietf.org, Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: Re: [DNSOP] Comments regarding the NSEC5
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.15
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: <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: Wed, 11 Mar 2015 16:53:09 -0000

> On Mar 11, 2015, at 9:39 AM, Jan Včelák <jan.vcelak@nic.cz> wrote:
> 
> NSEC5 proof is the FDH of domain name.
> NSEC5 hash is SHA-256 of NSEC5 proof.
> 
> I will clarify that.

Why not just do something simpler?  The only thing NSEC5 really differs in a way that counts is not in the NSEC record but really just the DNSKEY handling, having a separate key used for signing the NSEC* records.

So why define NSEC5 at all.


Instead, just specify a separate flag for the DNSKEY record, "NSEC-only", sign the NSEC3 dynamically, bada bing, bada boom, done!


For old resolvers, they just ignore the flag and treat it like any other DNSKEY record, and since the valid names are signed with the other key, while the NSEC* are signed with this key, it works just fine.

For upgraded resolvers, they follow the convention and only will accept RRSIGs for NSEC/NSEC3 with that DNSKEY record.

And then on the authority side, you just dynamically generate and sign the NSEC3 record that says H(name)-1 to H(name)+1 has no valid record and sign that with the NSEC-only key.



This way, you gain the protection against enumeration and the limited damage on key compromise property when validated by upgraded resolvers, and you still get the protection against enumeration when the resolver isn't upgraded, and you don't need to upgrade the resolver in order for this to be deployed.

--
Nicholas Weaver                  it is a tale, told by an idiot,
nweaver@icsi.berkeley.edu                full of sound and fury,
510-666-2903                                 .signifying nothing
PGP: http://www1.icsi.berkeley.edu/~nweaver/data/nweaver_pub.asc