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

Francis Dupont <Francis.Dupont@fdupont.fr> Wed, 19 July 2017 09:07 UTC

Return-Path: <Francis.Dupont@fdupont.fr>
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 5E6961317AD for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 02:07:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 wJhrDnjtlpjw for <dnsop@ietfa.amsl.com>; Wed, 19 Jul 2017 02:07:22 -0700 (PDT)
Received: from givry.fdupont.fr (givry.fdupont.fr [IPv6:2001:41d0:1:6d55:211:5bff:fe98:d51e]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C095912ECC0 for <dnsop@ietf.org>; Wed, 19 Jul 2017 02:07:21 -0700 (PDT)
Received: from givry.fdupont.fr (localhost [IPv6:::1]) by givry.fdupont.fr (8.14.7/8.14.7) with ESMTP id v6J8ol1c028029; Wed, 19 Jul 2017 10:50:47 +0200 (CEST) (envelope-from dupont@givry.fdupont.fr)
Message-Id: <201707190850.v6J8ol1c028029@givry.fdupont.fr>
From: Francis Dupont <Francis.Dupont@fdupont.fr>
To: Mukund Sivaraman <muks@isc.org>
cc: dnsop@ietf.org
In-reply-to: Your message of Tue, 18 Jul 2017 17:27:39 +0530. <20170718115739.GA32524@jurassic>
Date: Wed, 19 Jul 2017 10:50:47 +0200
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KkK591BwIxCfDd4ZhhaDjzfOLXM>
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: Wed, 19 Jul 2017 09:07:23 -0000

 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...

>  > It seems easier to remember that DNSSEC offers proofs for denial of
>  > existence.

=> still applies...

Regards

Francis.Dupont@fdupont.fr

PS: really if this is deployed I can see more "interesting" ways for misuses
than real benefits. Of course it can be a mean to make zone managers
to rush on DNSSEC...