Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight

Matthijs Mekking <matthijs@pletterpet.nl> Fri, 07 October 2016 12:35 UTC

Return-Path: <matthijs@pletterpet.nl>
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 4489812958A for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 05:35:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.92
X-Spam-Level:
X-Spam-Status: No, score=-6.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] 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 9E3szALNRMtB for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 05:34:59 -0700 (PDT)
Received: from dicht.nlnetlabs.nl (dicht.nlnetlabs.nl [185.49.140.10]) (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 1EDCA12958B for <dnsop@ietf.org>; Fri, 7 Oct 2016 05:34:58 -0700 (PDT)
Received: from [172.19.128.42] (vpn-10-mht.dyndns.com [216.146.45.33]) by dicht.nlnetlabs.nl (Postfix) with ESMTPSA id D9DA8A7AB for <dnsop@ietf.org>; Fri, 7 Oct 2016 14:34:55 +0200 (CEST)
Authentication-Results: dicht.nlnetlabs.nl; dmarc=none header.from=pletterpet.nl
To: dnsop@ietf.org
References: <1fc274b9-2164-1933-54e3-ce47ff48c8a3@gmail.com> <alpine.DEB.2.11.1610061100020.31786@grey.csi.cam.ac.uk>
From: Matthijs Mekking <matthijs@pletterpet.nl>
Message-ID: <6e8775f2-f1b1-3d4a-f58a-2269a00f9190@pletterpet.nl>
Date: Fri, 7 Oct 2016 14:34:51 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.3.0
MIME-Version: 1.0
In-Reply-To: <alpine.DEB.2.11.1610061100020.31786@grey.csi.cam.ac.uk>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/k2-8g2Sn4KmI8grH0WIZkX_o_no>
Subject: Re: [DNSOP] Reminder: WGLC for draft-ietf-dnsop-nsec-aggressiveuse ends Tonight
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: Fri, 07 Oct 2016 12:35:01 -0000

Tony,

On 06-10-16 13:18, Tony Finch wrote:
> I have read through the draft and sent a pull request with some minor
> editorial fixes.
>
> Here are some more substantial suggestions / questions. Sorry for being so
> late in the process.
>
>
> Would it make sense to be more specific about how to match queries to
> cached NSEC/NSEC3 records? By cross-referencing to the relevant part of
> the NSEC and NSEC3 specs, rather than repeating.

That would make total sense (at least for me). I tried to achieve that 
with my suggested text by repeating it, perhaps it's good enough to 
cross-reference. I am a bit worried though that the process for 
returning NSEC(3) records by an authoritative name server is slightly 
different than the process of for searching NSEC(3) records by a 
validating caching resolver, so that may be an argument for the 
repeating proposal.

Best regards,
   Matthijs


> The draft seems to imply that only one NSEC record is needed for denial of
> existence, and that wildcards are only problematic for NSEC3 - but
> wildcards can also trip up NSEC, if the covering NSEC does not also cover
> a relevant wildcard.
>
> eg (modified text) ...
>
> 5.1.  NSEC
>
>    Implementations which support aggressive use of NSEC SHOULD enable
>    this by default.  Implementations MAY provide a configuration switch
>    to disable aggressive use of NSEC and allow it to be enabled or
>    disabled per domain.
>
>    The validating resolver needs to check the existence of an NSEC RR
>    matching/covering the source of synthesis and an NSEC RR covering the
>    query name.
>
>    If denial of existance can be determined according to the rules set out
>    in RFC 4035 section 5.4, using NSEC records in the cache, then the
>    resolver can immediately return an NXDOMAIN or NODATA response.
>
> 5.2.  NSEC3
>
>    A validating resolver implementation MAY support aggressive use of
>    NSEC3.  If it does aggressive use of NSEC3, it MAY provide a
>    configuration switch to disable aggressive use of NSEC3 and allow it
>    to be enabled or disabled for specific zones.
>
>    NSEC3 aggressive negative caching is more difficult.  If the zone is
>    signed with NSEC3, the validating resolver needs to check the
>    existence of non-terminals and wildcards which derive from query
>    names.
>
>    If denial of existance can be determined according to the rules set out
>    in RFC 5155 sections 8.4, 8.5, 8.6, 8.7,, using NSEC3 records in the
>    cache, then the resolver can immediately return an NXDOMAIN or NODATA
>    response.
>
>
> TTLs
>
> Both NSEC and NSEC3 records are supposed to have a TTL matching the SOA
> MINIMUM field. This is not quite the same as RFC 2308 negative cache entry
> TTL, which is the minimum of the SOA MINIMUM and SOA TTL.
>
> Should there be text along the lines of:
>
> 5.3.  Consideration on TTL
>
>    The TTL value of negative information is especially important,
>    because newly added domain names cannot be used while the negative
>    information is effective.
>
>    Section 5 of RFC 2308 states that the maximum number of negative cache
>    TTL value is 3 hours (10800).  It is RECOMMENDED that validating
>    resolvers limit the maximum effective TTL value of negative responses
>    (NSEC/NSEC3 RRs) to this same value.
>
>    Section 5 of RFC 2308 also states that a negative cache entry TTL
>    is taken from the minimum of the SOA.MINIMUM field and SOA's TTL.
>    This can be less than the TTL of an NSEC or NSEC3 record, since their
>    TTL is equal to the SOA.MINIMUM field. (See RFC 4035 section 2.3 and
>    RFC 5155 section 3.)
>
>    A resolver that supports aggressive use of NSEC and NSEC3 should reduce
>    the TTL of NSEC and NSEC3 records to match the TTL of the SOA record in
>    the authority section of a negative response, if the SOA TTL is
>    smaller.
>
>
> Wildcards
>
> Should the box in section 7 say "positive responses" instead of "negative
> responses"?
>
> If so, there should probably also be a cross-ref to RFC 4035 section 5.3.4
> and RFC 5155 section 8.8 which both discuss validating positive wildcard
> responses. Similar to my suggestions for 5.1 and 5.2 above. I can provide
> text if you want.
>
>
> Security Considerations
>
> This should mention the impact of replay attacks. Something like,
>
> 	Although the TTL of NSEC/NSEC3 records is typically fairly short
> 	(minutes or hours), their RRSIG expiration time can be much
> 	further in the future (weeks). An attacker who is able to
> 	successfully spoof responses might poison a cache with old
> 	NSEC/NSEC3 records. If the resolver is NOT making aggressive use
> 	of NSEC/NSEC3, the attacker has to repeat the attack for every
> 	query. If the resolver IS making aggressive use of
> 	NSEC/NSEC3, one successful attack would be able to suppress many
> 	queries for new names, up to the negative TTL.
>
>
> Tony.
>