Re: [DNSOP] Comments regarding the NSEC5

Florian Weimer <fweimer@redhat.com> Thu, 12 March 2015 10:31 UTC

Return-Path: <fweimer@redhat.com>
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 45BDD1A9138 for <dnsop@ietfa.amsl.com>; Thu, 12 Mar 2015 03:31:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.612
X-Spam-Level:
X-Spam-Status: No, score=-6.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 m74qL9DvSKCv for <dnsop@ietfa.amsl.com>; Thu, 12 Mar 2015 03:31:43 -0700 (PDT)
Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) (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 6B1951A9141 for <dnsop@ietf.org>; Thu, 12 Mar 2015 03:31:43 -0700 (PDT)
Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id t2CAVfeo006487 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Thu, 12 Mar 2015 06:31:41 -0400
Received: from oldenburg.str.redhat.com ([10.10.116.39]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id t2CAVdDo008094 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 12 Mar 2015 06:31:40 -0400
Message-ID: <55016B09.8080106@redhat.com>
Date: Thu, 12 Mar 2015 11:31:37 +0100
From: Florian Weimer <fweimer@redhat.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Jan Včelák <jan.vcelak@nic.cz>, dnsop@ietf.org
References: <55002098.5060709@redhat.com> <55006FC7.1030206@nic.cz> <17FB96B6-B44C-4C9B-A68E-112C5EAE0CA3@icsi.berkeley.edu> <3070134.2yIek5FY2o@pc-cznic4>
In-Reply-To: <3070134.2yIek5FY2o@pc-cznic4>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.68 on 10.5.11.24
Archived-At: <http://mailarchive.ietf.org/arch/msg/dnsop/iOtlkKhIrHYixPKt1wClHVceeaI>
Cc: 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: Thu, 12 Mar 2015 10:31:45 -0000

On 03/12/2015 11:15 AM, Jan Včelák wrote:
> On Wednesday, March 11, 2015 09:52:55 AM Nicholas Weaver wrote:
>> 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!
> 
> This would not work. Anyone holding the NSEC-only private key could fake 
> denying answers for the zone. So if your zone is slaved by a less-trusted 
> party, they could still manipulate your zone. This is not possible with NSEC5.

They can still respond with SERVFAIL instead of supplying a signed
answer, achieving roughly the same result.

A better argument would be support for opt out, where signatures from
the online key could introduce unauthorized positive answers.  It's
still not a very strong argument, admittedly.  The DNS software itself
is likely signed by a key which is kept online (more or less).  Online
keys are less threatening than they used to be, and we aren't even
talking about long-term keys baked into software, but short/medium-term
keys which are easily replaced.

And does anyone actually use opt out with NSEC3?

-- 
Florian Weimer / Red Hat Product Security