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

[Matthijs Mekking <[e-mail]>]

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