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

Mukund Sivaraman <muks@isc.org> Tue, 18 July 2017 11:57 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 2262F1288B8 for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 04:57:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.265
X-Spam-Level:
X-Spam-Status: No, score=0.265 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, 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 Vx3aFfERLevf for <dnsop@ietfa.amsl.com>; Tue, 18 Jul 2017 04:57:45 -0700 (PDT)
Received: from mail.banu.com (mail.banu.com [IPv6:2a01:4f8:140:644b::225]) by ietfa.amsl.com (Postfix) with ESMTP id E914512785F for <dnsop@ietf.org>; Tue, 18 Jul 2017 04:57:44 -0700 (PDT)
Received: from jurassic (unknown [115.118.30.175]) (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 9E0B056A04AF; Tue, 18 Jul 2017 11:57:42 +0000 (GMT)
Date: Tue, 18 Jul 2017 17:27:39 +0530
From: Mukund Sivaraman <muks@isc.org>
To: Francis Dupont <Francis.Dupont@fdupont.fr>
Cc: dnsop@ietf.org
Message-ID: <20170718115739.GA32524@jurassic>
References: <20170718094654.GA31988@jurassic> <201707181117.v6IBHwLn047420@givry.fdupont.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <201707181117.v6IBHwLn047420@givry.fdupont.fr>
User-Agent: Mutt/1.8.3 (2017-05-23)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/jYopwNRT5wsVTCCpE5GoMAn87cI>
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 11:57:46 -0000

Hi Francis

On Tue, Jul 18, 2017 at 01:17:58PM +0200, Francis Dupont wrote:
>  In your previous mail you wrote:
> 
> >  There are still many popular unsigned zones, many of which don't look
> >  like they will be signed soon due to operational and other reasons.
> >  
> >  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?
> 
> => I can't parse your message:
>  - unsigned zones have no zone keys

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

>  - DNS cookie was designed to give a return routability proof for the client,
>   not the server
>  - there is no NSEC/NSEC3 in an unsigned zone
> Perhaps you mean to return a synthesized NSEC/NSEC3 and the DNS COOKIE is
> as usual required to avoid amplification DoS.

This was discussed during the ISC 2017 all-hands; I don't remember if
you were in the meeting when we discussed it (I think the meeting topic
was about DoS mitigation measures).

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.

> But what will be the signing key (including on the client side) and
> what to put in the NSEC/NSEC3? Perhaps this applies only to authoritative
> servers of the (unsigned) zone?
> It seems easier to remember that DNSSEC offers proofs for denial of existence.

		Mukund