Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use

Petr Špaček <petr.spacek@nic.cz> Tue, 18 July 2017 13:14 UTC

Return-Path: <petr.spacek@nic.cz>
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 69D3313167D for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 06:14:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.001
X-Spam-Level:
X-Spam-Status: No, score=-7.001 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
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 OgReVNEb1jvv for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 06:14:06 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (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 29C9312EB8C for <dnsop@ietf.org>; Tue, 18 Jul 2017 06:14:06 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5] (unknown [IPv6:2001:1488:fffe:6:b8dd:c7ff:fe99:40e5]) by mail.nic.cz (Postfix) with ESMTPSA id A822B6226C for <dnsop@ietf.org>; Tue, 18 Jul 2017 15:14:04 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1500383644; bh=bPVr/CuRKVI7H+hCaQeqk8+3XQHbdwC2Gim22U6rpWk=; h=To:From:Date; b=TrWUiPU2KXj4RlOCu70Bn/ww+6yob1+y1cHY65Ny9TiPPNfr4dDG1nNaNcadCWoel HuS8i/K6R+jVbqSdclKxbrCQOL9SZ7lV8hWFQyl8SYs6bXVaiTMyI4CPmRVW/O/xmq pXp3DescAy5HFkkw/6rFGgKY2DV+8m0J8Of7NXQg=
To: dnsop@ietf.org
References: <20170718094654.GA31988@jurassic> <6EE82876-6085-42FA-B2F1-850E9EAE6083@vpnc.org> <20170718125056.GA7982@jurassic>
From: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>
Organization: CZ.NIC
Message-ID: <24c25fc8-af41-07bd-15b0-306aa5da3f22@nic.cz>
Date: Tue, 18 Jul 2017 15:14:04 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1
MIME-Version: 1.0
In-Reply-To: <20170718125056.GA7982@jurassic>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KPxbs38PJ94tJIptZ-3lPhBdF28>
Subject: Re: [DNSOP] NSEC/NSEC3 for unsigned zones and aggressive use
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.22
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: Tue, 18 Jul 2017 13:14:08 -0000

On 18.7.2017 14:50, Mukund Sivaraman wrote:
> Hi Paul
> 
> On Tue, Jul 18, 2017 at 02:35:31PM +0200, Paul Hoffman wrote:
>> On 18 Jul 2017, at 11:46, Mukund Sivaraman wrote:
>>
>>> Will you give some thought and reply with your opinion on NSEC/NSEC3 for
>>> unsigned zones requiring the DNS COOKIE option in transmission, that can
>>> be used with draft-ietf-dnsop-nsec-aggressiveuse?
>>
>> Of what value is the result? Is it worth the hassle for the zone admin?
> 
> It is to put draft-ietf-dnsop-nsec-aggressiveuse to use with unsigned
> zones. A zone admin would not have to do anything operationally except
> enable/disable the feature.
> 
> Dealing with water torture and some other attacks have had several
> band-aid approaches that don't always work well in practice. The most
> promising (and what feels correct) is
> draft-ietf-dnsop-nsec-aggressiveuse, but it doesn't work for unsigned
> zones.

For me this is an incentive to get more zones signed, not to add kludges
just for unsigned ones.

There surely are "operational and other reasons" not to sign zone
associated with some cost. Signing and serving signed zone have cost_1
and serving unsigned zone has cost_2 (which needs to incorporate cost of
attacks mitigated by DNSSEC).

Eventually cost_2 of serving unsigned zone might get high enough so
solving "operational and other reasons" might be cheaper than cost_1
paying for signing and serving signed zone. I would wait for that.

-- 
Petr Špaček  @  CZ.NIC