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 19:27 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 7611C129630 for <dnsop@ietfa.amsl.com>; Thu, 5 Jan 2017 11:27:32 -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 3-KA1hXE6cv6 for <dnsop@ietfa.amsl.com>; Thu, 5 Jan 2017 11:27:30 -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 46FEB12961F for <dnsop@ietf.org>; Thu, 5 Jan 2017 11:27:30 -0800 (PST)
Received: from [192.168.8.180] (wall-a.vs.uni-duisburg-essen.de [134.91.78.130]) (authenticated bits=0) by mailout.uni-due.de (8.13.1/8.13.1) with ESMTP id v05JRR5B011516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Jan 2017 20:27:27 +0100
To: Paul Hoffman <paul.hoffman@vpnc.org>
References: <FEDF56ED-D27D-44A7-8989-C8920BC6C1CE@icsi.berkeley.edu> <98A24DD4-91B6-4FFC-8A6F-C26D75175B85@vpnc.org>
From: Matthäus Wander <matthaeus.wander@uni-due.de>
Organization: Universität Duisburg-Essen
Message-ID: <f6125e52-e8a7-a872-7a6e-b2873e1ad1a2@uni-due.de>
Date: Thu, 05 Jan 2017 20:27:19 +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: <98A24DD4-91B6-4FFC-8A6F-C26D75175B85@vpnc.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="------------ms030206030203070103070901"
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/dDlK7WLnkK0qqW9DK49BOU-dE7k>
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 19:27:32 -0000

* Paul Hoffman [2017-01-05 18:05]:
>> NSEC3 lies work today, but people worry that NSEC3 might have server
>> compromise compromise the ZSK.
> 
> NSEC3 lies can also be created with pre-computing, but at a cost of
> greatly increasing the size of the zone.

NSEC/NSEC3 lies prevent enumeration effectively when they're minimally
covering because it's infeasible to ever collect such a chain.

A pre-computed chain does not provide the same benefit. It increases the
enumeration cost in terms of network queries (CPU time is of less
importance here because the collection process is network-bound except
for the very last few NSEC3 records). Enumeration remains feasible with
pre-computed chains unless you re-salt and re-sign the zone in an
interval, which is shorter than the duration needed to send one query
for each NSEC3 record in a zone.

Regards,
Matt