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

Mukund Sivaraman <muks@isc.org> Wed, 04 January 2017 18:24 UTC

Return-Path: <muks@isc.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 56E931296BF for <dnsop@ietfa.amsl.com>; Wed, 4 Jan 2017 10:24:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.235
X-Spam-Level:
X-Spam-Status: No, score=-1.235 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_SOFTFAIL=0.665] autolearn=no 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 OvreXftTZb6A for <dnsop@ietfa.amsl.com>; Wed, 4 Jan 2017 10:24:23 -0800 (PST)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 3FFD4129A10 for <dnsop@ietf.org>; Wed, 4 Jan 2017 10:24:23 -0800 (PST)
Received: from jurassic (unknown [115.118.146.77]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.banu.com (Postfix) with ESMTPSA id 6867D2FA00D5; Wed, 4 Jan 2017 18:24:20 +0000 (GMT)
Date: Wed, 04 Jan 2017 23:54:16 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Nicholas Weaver <nweaver@icsi.berkeley.edu>
Message-ID: <20170104182415.GA29444@jurassic>
References: <FEDF56ED-D27D-44A7-8989-C8920BC6C1CE@icsi.berkeley.edu>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="jI8keyz6grp/JLjh"
Content-Disposition: inline
In-Reply-To: <FEDF56ED-D27D-44A7-8989-C8920BC6C1CE@icsi.berkeley.edu>
User-Agent: Mutt/1.7.1 (2016-10-04)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/v9aEz6mJ4hcCf1GOiPBnevLkl3A>
Cc: dnsop <dnsop@ietf.org>
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:24:24 -0000

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.

		Mukund