Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...

Nicholas Weaver <nweaver@icsi.berkeley.edu> Wed, 04 January 2017 18:28 UTC

Return-Path: <nweaver@icsi.berkeley.edu>
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 EEEA21296C1 for <dnsop@ietfa.amsl.com>; Wed, 4 Jan 2017 10:28:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.001
X-Spam-Level:
X-Spam-Status: No, score=-5.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-3.1, SPF_PASS=-0.001] 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 sb7hVt7jrFjD for <dnsop@ietfa.amsl.com>; Wed, 4 Jan 2017 10:28:12 -0800 (PST)
Received: from rock.ICSI.Berkeley.EDU (rock.ICSI.Berkeley.EDU [192.150.186.19]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61521126D74 for <dnsop@ietf.org>; Wed, 4 Jan 2017 10:28:12 -0800 (PST)
Received: from localhost (localhost.localdomain [127.0.0.1]) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id 527E82C405C; Wed, 4 Jan 2017 10:28:12 -0800 (PST)
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 KpOJzqzPNAPA; Wed, 4 Jan 2017 10:28:11 -0800 (PST)
Received: from gala.icsi.berkeley.edu (gala.icir.org [192.150.187.130]) (Authenticated sender: nweaver) by rock.ICSI.Berkeley.EDU (Postfix) with ESMTP id DF7E72C4059; Wed, 4 Jan 2017 10:28:11 -0800 (PST)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.2 \(3259\))
From: Nicholas Weaver <nweaver@icsi.berkeley.edu>
In-Reply-To: <20170104182415.GA29444@jurassic>
Date: Wed, 04 Jan 2017 10:28:11 -0800
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED164FC2-21B2-411B-B828-9D9617D82F30@icsi.berkeley.edu>
References: <FEDF56ED-D27D-44A7-8989-C8920BC6C1CE@icsi.berkeley.edu> <20170104182415.GA29444@jurassic>
To: Mukund Sivaraman <muks@isc.org>
X-Mailer: Apple Mail (2.3259)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/CMxabqNZqyPlE7ARtV08KVt_nLU>
Cc: dnsop <dnsop@ietf.org>, Nicholas Weaver <nweaver@icsi.berkeley.edu>
Subject: Re: [DNSOP] Stupid thought: why not an additional DNSKEY record flag: NSEC* only...
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: Wed, 04 Jan 2017 18:28:14 -0000

> On Jan 4, 2017, at 10:24 AM, Mukund Sivaraman <muks@isc.org> wrote:
> 
> Hi Nicholas
> 
> On Wed, Jan 04, 2017 at 09:33:04AM -0800, Nicholas Weaver wrote:
>> This way, you can deploy this solution today using white lies, and as
>> resolvers are updated, this reduces the potential negative consequence
>> of a key compromise to “attacker can only fake an NXDOMAIN”, allowing
>> everything else to still use offline signatures.
>> 
>> Combine with caching of the white lies to resist DOS attacks and you
>> have a workable solution that prevents zone enumeration that is
>> deployable today and has improved security (key can only fake
>> NXDOMAIN) tomorrow.
> 
> Assume an attacker is able to spoof answers, which is where DNSSEC
> validation helps. If a ZSK is leaked, it becomes a problem only when an
> attacker is able to spoof answers (i.e., perform the attack).
> 
> What you're saying is that with a special NSEC3-only DNSKEY compromise,
> "attacker can only fake an NXDOMAIN". If an attacker can fake NXDOMAINs
> and get the resolver to accept them, that's as bad. The attacker can
> deny all answers in the zone by presenting valid negative answers. This
> is why we have proof of non-existence that needs to be securely
> validated. A special NSEC3-only-DNSKEY's compromise isn't a better
> situation than a ZSK compromise.

An attacker in that position can just put in garbage, and you get SERVFAIL instead of NXDOMAIN, regardless of whether the attacker has compromised the key or not.

This is partially why the provable denial is somewhat silly as I can have the same effect as a denial of service using other mechanisms that the cryptography doesn’t stop.

So having a key that can only be used for provable denial compromised by an attacker is, yeah, not great, but not some horrid catastrophe. 

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