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

Warren Kumari <warren@kumari.net> Fri, 07 October 2016 19:03 UTC

Return-Path: <warren@kumari.net>
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 E67A412940A for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 12:03:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=kumari-net.20150623.gappssmtp.com
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 GOZtCn1xPlNa for <dnsop@ietfa.amsl.com>; Fri, 7 Oct 2016 12:03:44 -0700 (PDT)
Received: from mail-qt0-x229.google.com (mail-qt0-x229.google.com [IPv6:2607:f8b0:400d:c0d::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5323127735 for <dnsop@ietf.org>; Fri, 7 Oct 2016 12:03:44 -0700 (PDT)
Received: by mail-qt0-x229.google.com with SMTP id q7so25415161qtq.1 for <dnsop@ietf.org>; Fri, 07 Oct 2016 12:03:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kumari-net.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0ukmEFRom2PEc+5CQzUVFi8rV6m7SyRESV1gUbTGVp8=; b=JSxdInIudHdgLfpd3MVR91EKmDnLR/y3w6MnTHHEHcjVjfGfPGNBSMCLdeXE9NMvg6 knAhSm6QfQp3+AbO/DbcYh0oQavP4knIKE/KiAJ6kObPaYm1oFVSDyy6fobwdZLhyemS JCY5+uneE4k/wfQN9KIu1Psin05Lec5elbbyJSuPpgm7vqQQdCGXXvjSLqU8/6URwmnH v60ohRfLGmjoSQRT6pDq58Ty6aPTcyZVnPiYmR7fZDpiTyzrttxH2mREOwva/rWP2ZWW UEXW1R5GPVZFEJ0c8N5KmqZBj+FJTo0QxJYugcpemwYvEJfPzLC1fM1ulmEf2F55FhTZ /JhQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0ukmEFRom2PEc+5CQzUVFi8rV6m7SyRESV1gUbTGVp8=; b=bdRQZdzdDuL0vNWCNPZrKL0oYGr1N+TwwtKBntafhG03+pqxj8izF9FtG/R9v6tRAz 8rodkN+MKKfuSSER9+yojjISlcE12VVzplY4/rYqt8MtDUcROAofWf5lT4BZC+vggU5r fVG1rBdR2qLooBYPBz5AggNn6eu2OAKR6gP9i6RO4Tma1Ik4Sd+J2ImpiLPtimaiDzGF LRKz7YwyUq9poPe7M/Uu2Q7s45O4FNdrdteyp5/ReLMTtFnaNGVYQpl5U+vx7qm+Qmob pPlvqhg2lXFbhzvQLsh7+LVNFafzFkz3XFQ1SVyvy4bXXKOeApV+pCWvcBCFqEmAyZHE kvBw==
X-Gm-Message-State: AA6/9RkkquFS3KrkVxT+qbhuPPJL5k9lYXM4rzbNGpH6IhgDirVJqu2b9vr9N+XkrU+WcEShsqkXCetLGwX2VKEa
X-Received: by 10.200.49.85 with SMTP id h21mr15809214qtb.34.1475867023821; Fri, 07 Oct 2016 12:03:43 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.55.147.196 with HTTP; Fri, 7 Oct 2016 12:03:13 -0700 (PDT)
In-Reply-To: <alpine.DEB.2.11.1610061100020.31786@grey.csi.cam.ac.uk>
References: <1fc274b9-2164-1933-54e3-ce47ff48c8a3@gmail.com> <alpine.DEB.2.11.1610061100020.31786@grey.csi.cam.ac.uk>
From: Warren Kumari <warren@kumari.net>
Date: Fri, 7 Oct 2016 15:03:13 -0400
Message-ID: <CAHw9_i+vJjy-ARvkN1s33AUXdMaKbOsKRUhRLhxEFm1yiijN3A@mail.gmail.com>
To: Tony Finch <dot@dotat.at>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Sqmei2OSPQcMz2Cgf8WFE9HrivM>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, Akira Kato <kato@wide.ad.jp>, dnsop <dnsop@ietf.org>
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 19:03:47 -0000

On Thu, Oct 6, 2016 at 7:18 AM, Tony Finch <dot@dotat.at> wrote:
> I have read through the draft and sent a pull request with some minor
> editorial fixes.

Thank you. These have been accepted / incorporated.

>
> Here are some more substantial suggestions / questions. Sorry for being so
> late in the process.
>

No apologies needed, thanks for feedback.

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

Yup!

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

DONE.
Thank you for providing text. It certainly makes it easier to
understand / address comments.


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

DONE.
Thank you -- I reordered / reworded things slightly to make it flow
somewhat better, but it is basically still your text.

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

... probably :-)

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

DONE.
This is great. I used your text, thank you.

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

NOT DONE.
Yes please. That would be awesome!
I had removed Section 7 (Wildcards) because I thought that that was
what the WG wanted, but I apparently misjudged that. I have now put it
back, and tried to reconcile the positive and negative test, but do
not have any text like the above. I'd really appreciate some!

I have put beck the original Wildcard text, and am committing it to
GitHub. I will then try address the original wording issues which made
me remove it in the first place...

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

DONE.
Excellent. Incorporated. Thank you.


Thank you, I really appreciate everyone's assistance.
W


>
> Tony.
> --
> f.anthony.n.finch  <dot@dotat.at>  http://dotat.at/  -  I xn--zr8h punycode
> Wight, Portland, Plymouth: East 5 to 7, occasionally 4 later. Moderate or
> rough. Showers later. Good.



-- 
I don't think the execution is relevant when it was obviously a bad
idea in the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair
of pants.
   ---maf