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

Matthäus Wander <matthaeus.wander@uni-due.de> Thu, 05 January 2017 13:13 UTC

Return-Path: <matthaeus.wander@uni-due.de>
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 18ECB129450 for <dnsop@ietfa.amsl.com>; Thu, 5 Jan 2017 05:13:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.3
X-Spam-Level:
X-Spam-Status: No, score=-7.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-3.1] 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 7BhVvpyjIMTd for <dnsop@ietfa.amsl.com>; Thu, 5 Jan 2017 05:13:23 -0800 (PST)
Received: from mailout.uni-due.de (mailout.uni-due.de [132.252.185.19]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B1DBC129437 for <dnsop@ietf.org>; Thu, 5 Jan 2017 05:13:22 -0800 (PST)
Received: from [192.168.8.180] (wall-a.vs.uni-due.de [134.91.78.130]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id v05DDJ3n029258 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 14:13:20 +0100
To: Mukund Sivaraman <muks@isc.org>
References: <FEDF56ED-D27D-44A7-8989-C8920BC6C1CE@icsi.berkeley.edu> <20170104182415.GA29444@jurassic>
From: Matthäus Wander <matthaeus.wander@uni-due.de>
Organization: Universität Duisburg-Essen
Message-ID: <7decac93-6437-40a5-3c71-f33e18cbb43c@uni-due.de>
Date: Thu, 05 Jan 2017 14:13:12 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <20170104182415.GA29444@jurassic>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms020400010405060306060302"
X-Virus-Scanned: Clam Anti Virus - http://www.clamav.net
X-Spam-Scanned: SpamAssassin: 3.002004 - http://www.spamassassin.org
X-Scanned-By: MIMEDefang 2.57 on 132.252.185.19
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/l5jMZ_XE9Q9dmZVi4aVo9b1ao9g>
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: Thu, 05 Jan 2017 13:13:25 -0000

* Mukund Sivaraman [2017-01-04 19:24]:
> 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.

You're right if you're only considering denial of service.
If you take phishing or email hijacking into account, an NSEC3-only
compromise is a better situation than a ZSK compromise (or at least a
different attack class, whether or not better).

With DANE, however, it's not just denial of service anymore: NXDOMAIN
spoofing cancels the protection provided by DANE.

So we have the cost of a protocol change vs. the benefit of protecting
from bogus records (but not from DoS or DANE downgrade)...

Regards,
Matt