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

Mukund Sivaraman <muks@isc.org> Fri, 21 July 2017 09:23 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 4E640127869 for <dnsop@ietfa.amsl.com>; Fri, 21 Jul 2017 02:23:07 -0700 (PDT)
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 pdFxcpfGTlSi for <dnsop@ietfa.amsl.com>; Fri, 21 Jul 2017 02:23:06 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [46.4.129.225]) by ietfa.amsl.com (Postfix) with ESMTP id 16484126557 for <dnsop@ietf.org>; Fri, 21 Jul 2017 02:23:06 -0700 (PDT)
Received: from jurassic (unknown [115.117.171.118]) (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 0547956A02DB; Fri, 21 Jul 2017 09:23:03 +0000 (GMT)
Date: Fri, 21 Jul 2017 14:53:01 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Petr Špaček <petr.spacek@nic.cz>
Cc: dnsop@ietf.org
Message-ID: <20170721092301.GA3781@jurassic>
References: <201707190850.v6J8ol1c028029@givry.fdupont.fr> <eb8b12e6-1a0e-38b7-0b31-8c242741536e@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <eb8b12e6-1a0e-38b7-0b31-8c242741536e@nic.cz>
User-Agent: Mutt/1.8.3 (2017-05-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qLLMDjkC94uKWIw-GW1mmOiT5Yk>
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: Fri, 21 Jul 2017 09:23:07 -0000

On Fri, Jul 21, 2017 at 10:24:35AM +0200, Petr Špaček wrote:
> On 19.7.2017 10:50, Francis Dupont wrote:
> >  In your previous mail you wrote:
> > 
> >>  NSEC needs no keys, only their RRSIGs would which wouldn't exist in
> >>  unsigned zones. In this case the unsigned NSEC would also not be part of
> >>  the zone (it would have to be synthesized and maintained outside the
> >>  zone).
> > 
> > => but it is created by an authoritative server, isn't it?
> > And as it is synthesized I can't see a good reason to use NSEC3 instead.
> > 
> >>  Because an unsigned/unauthenticated NSEC/NSEC3 has the potential to nix
> >>  entire zones, when it was discussed, Mark Andrews suggested that
> >>  requiring DNS COOKIE to further reduce the chance of cache poisoning
> >>  (more than source port randomization and random message ID) could be a
> >>  reasonable idea to think about.
> > 
> > => it adds a nonce so another (short) bunch of unpredictable bits.
> > As NSEC is not signed it is more than vulnerable to on-the-path attacks.
> > I am afraid it is first a massive zone destruction weapon and after
> > perhaps an optimization...
> 
> Oh yes, very good point Francis. Let me repeat that I'm against this
> proposal.

The zone is unsigned. An on-path attacker can do pretty much whatever he
pleases anyway including poisoning cache and denying service.

The addition of the cookie was to prevent the risk of an off-path attack
becoming a massive zone destruction weapon.

		Mukund