Re: [secdir] secdir review of draft-ietf-dnsop-nsec-aggressiveuse

Warren Kumari <warren@kumari.net> Thu, 30 March 2017 19:00 UTC

Return-Path: <warren@kumari.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31C0A129A4E for <secdir@ietfa.amsl.com>; Thu, 30 Mar 2017 12:00:42 -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, RCVD_IN_DNSWL_NONE=-0.0001] 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 k4aFjDP0ZF-c for <secdir@ietfa.amsl.com>; Thu, 30 Mar 2017 12:00:33 -0700 (PDT)
Received: from mail-qt0-x232.google.com (mail-qt0-x232.google.com [IPv6:2607:f8b0:400d:c0d::232]) (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 A17DF129AA3 for <secdir@ietf.org>; Thu, 30 Mar 2017 12:00:26 -0700 (PDT)
Received: by mail-qt0-x232.google.com with SMTP id x35so47563531qtc.2 for <secdir@ietf.org>; Thu, 30 Mar 2017 12:00:26 -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:content-transfer-encoding; bh=JRkJ5QbawCMIc+J4++k3hfs1cVfiLkKfiuRk0Mrv7ic=; b=dmvPS1slNT2cfCNJNYyWh0bBWWYUjurZahWQqhJtahv+GdRjES6AhFF4puMc+jtPPr 6pq4QEa1NG/BBfL97Dl4sEMU9U6I5ijY+cMAm7NhDrIqMltm32aTTqgQUJx/jBE00JrU OyPTosGpsblkCPrKla8S4J914vOoM9vysakoR4cULcMkHU42lAfeyj17Dq05FwcDOaTm RYcez0xNtFl9bzdWPSfqLIvT3PXlIp421TusJwQ+n/j5kAXLMPbZ7+OtORKYRqGPJKuk ns89EoR4N5A3fTyO5cMj8WqrfYcYRptop0sVH+v/dxI6Mkl/nmFwjq3ZUZD4otZL+p4B DWMA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=JRkJ5QbawCMIc+J4++k3hfs1cVfiLkKfiuRk0Mrv7ic=; b=WAP4WEgqRkHNdM6YfoPD3NQ41Telxr03qu7bpl7Bl4QoIsnRVydwz2PuHZLdDx18sb /FYggh5LbpdYtMmC2QO/rJJPCfcAVOAtNYKtFQLd7ej8QysBpfRNaA8D92Lhf9S2F3z6 jz1eR3XyDAfOgIklaHgeqd7Hp7gDnMm2I5LqJvfLjJrHTABNyEzZmj7Bxy8EKQll9nyV 2O7NYEHKMNfr7aWLDvfcORpjGfoESNQCSY19Fqp4IONfFh1xkCYaIPnL+oRimfgAuaTs 8eDXHen4Z49406Eoh4cmJFSGSKYhP6K3kp4h/VmApjEOhf8AxBYt9hJ5tNP889gRWmQB ZScA==
X-Gm-Message-State: AFeK/H1YYp7mv+I61wigG/rumdnmSx2K3UWDRaQXj8QwdPinQlyuY9E+ObxSvsxbMVQ4eOsUsaTfcbHPjMrdeR6N
X-Received: by 10.200.43.185 with SMTP id m54mr1354179qtm.122.1490900423848; Thu, 30 Mar 2017 12:00:23 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.12.177.11 with HTTP; Thu, 30 Mar 2017 11:59:43 -0700 (PDT)
In-Reply-To: <F8D0F7F4-414B-44A4-B6D0-428D506D97C7@tislabs.com>
References: <F8D0F7F4-414B-44A4-B6D0-428D506D97C7@tislabs.com>
From: Warren Kumari <warren@kumari.net>
Date: Thu, 30 Mar 2017 13:59:43 -0500
Message-ID: <CAHw9_iL-UdKNsBSP1imzOg1PcjAvhk=b7Uw+nG-gDeQSOfgUxQ@mail.gmail.com>
To: Sandra Murphy <sandy@tislabs.com>
Cc: IETF Security Directorate <secdir@ietf.org>, draft-ietf-dnsop-nsec-aggressiveuse@ietf.org, dnsops-chairs@ietf.org, The IETF <ietf@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/secdir/CYTUCsvVIw8SzvCU2uF-qt58R9w>
Subject: Re: [secdir] secdir review of draft-ietf-dnsop-nsec-aggressiveuse
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 30 Mar 2017 19:00:42 -0000

On Tue, Mar 28, 2017 at 11:34 AM, Sandra Murphy <sandy@tislabs.com> wrote:
> I have reviewed this document as part of the security directorate's
> ongoing effort to review all IETF documents being processed by the
> IESG.  These comments were written primarily for the benefit of the
> security area directors.  Document editors and WG chairs should treat
> these comments just like any other last call comments.

Thank you very much for your review, and getting it in early, it makes
addressing them much easier.


>
> This document suggests that resolvers should use NSEC/NSEC3 proof of non-existence for a domain name in a received query to generate a negative reply, rather than relying on the current spec of an exact match to the domain name.  Generating positive replies from wildcard answers is also suggested.
>
> The motivation is improvements in latency for queriers and improvements in bandwidth and CPU load on recursive resolvers and validation servers.
>
> I have no serious objections about the draft.
>
> I am curious about my thought that an attacker might find this of benefit, as they can learn of non-existence in just one query, rather than every name in a NSEC denied range. I know zone walking is a concern to some, but I do not know if ease of determining non-existence is also a concern.


I may have missed something, but I do not see the concern -- an
attacker can already learn of non-existence in just one query; that is
exactly what NSEC (already) provides.
If an attacker queries e.g the root for .belkin they get back (trimmed):
$ dig +dnssec belkin
beer. 44025 IN NSEC bentley. NS DS RRSIG NSEC

This tells the attacker that nothing exists between beer and bentley
(in one query). All that this document does is optimize the recursive
server so that, if the attacker tries to instead do e.g a dictionary
attack and ask many names between beer and bentley the recursive (and
auths) have less work to do. The attacker only advantage to the
attacker is that they have to wait slightly less time doing a
dictionary attack -- but, they would be much better off asking for the
(existing) NSEC info directly.

>
> Section 7 explicitly spells out the changes to RFC4035 are explicitly spelled
> out as to what is removed and what replaces it.  Section 5 is not so clearly
> delineated.

Yup. At one point we had the changes explicitly spelled out in both,
the WG felt that this was overly long and duplicating the text was
confusing.

>
> The last paragraph of 5., nothing in 5.1 or 5.2, and the last paragraph of 5.3
> use SHOUD/MUST/MAY kinds of language.  For the paragraphs that don’t - should
> they?  For the paragraphs that do, is this additional behavior or a
> replacement for existing spec (i.e. like the section 7 update to RFC4035).
> If a replacement, a replacement of what?  If not, where do the new paragraphs
> fit?
>

I don't think that these bits to need the 2119 language - they are
more explanatory, and providing explanation / justification for the
change baing made to RFC4035 (which is updated in Section 7).


> The following is a sequential set of comments, not in importance order.
>
> page 3
>
>   This document updates RFC 4035 to allow recursive resolvers to use
>   NSEC/NSEC3 resource records to synthesize negative answers from the
>   information they have in the cache.
>
> re: recursive resolvers - is the technique not applicable to stub resolvers?
> (I do see references to stub resolver caches in a web search, but you can’t
> trust the web.)

Good catch -- we fixed a similar issue in the Abstract, but missed it here.

>
>  [RFC8020], and [I-D.vixie-dnsext-resimprove] proposes first steps to
>   using NXDOMAIN information for more effective caching.  This takes
>   this technique further.
>
> Unless rfc8020 and the vixie draft are the same thing (don’t think so),
> should be “propose”.
>
>
> Too many uses of “this” in that last sentence - I presume you mean
>   This draft takes those previous techniques further.

Thank you.  I changed these to:
[RFC8020] and [I-D.vixie-dnsext-resimprove propose steps to using
NXDOMAIN information for more effective caching. This document takes
this technique further.

>
>
> page 4
>
>   If a validating resolver receives a query for cat.example.com, it
>   contacts its resolver (which may be itself)
>
> Maybe
>
>   If a validating resolver receives a query for cat.example.com, it
>   contacts its recursive resolver (which may be itself)

Thank you -- I believe that the current is more correct; in most cases
the validating resolver will be a recursive resolver and will be
contacting a authoritative server. In a few cases (currently, in the
future this may change as validating stubs become common) it will be a
stub contacting a recursive, so the text in the draft covers both
cases.

>
> About:
>
>   and also has
>   privacy implications (e.g: typos leak out further than necessary).
>
> Does it also make certain explorations easier, where someone can find out a range
> that does not exist by doing just one query rather than query every name in the
> range?  Or is that sort of exploration already prevented by other techniques?

Nope; as above. Attackers already have the capability to find ranges
which do not exist (querying for the NSEC record).

>
>   If a query is received for leek.example.org, it contacts its resolver
>   (which may be itself)
>
> I suggest “the resolver contacts its <recursive> resolver” - the query is not
> doing the contacting.

Thank you. I changed it to:
"If a query is received for leek.example.org, the system contacts its
resolver (which may be itself) to query..."

I think that this addresses your comment in a more general manner.

>
>
> page 6
>
> section 5.1 and 5.2 say “resolver can immediately return” - is this meant
> to specify new behavior, should they have SHOULD/MAY/MUST kinds of words?

I don't *think* so -- it means that is has the ability to; other text
suggests what it actually should to.

>
> page 7
>
>   Section 5 of [RFC2308] states that the maximum number of negative
>   cache TTL value is 3 hours (10800).
>
> I don’t find a maximum in RFC2308.  I do find:
>                    Values of one to three hours have been found to work well
>   and would make sensible a default.
> Did I miss something?
>

See below.

>
> “the maximum number of negative cache TTL value is” - a bit twisty.  Did you
> mean something like:
>
>  Section 5 of [RFC2308] states that the maximum negative cache TTL value is”
>
> otherwise, I’d think “number of … values”, but even so I don’t think there are
> multiple values here. Are there?

Nope, you did not miss anything, and yes, yes that was twisty - 'twas
an artifact of poor editing.

I changed this to be:
Section 5 of [RFC2308 suggests a maximum default negative cache TTL
value of 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.

>
> page 9
>
> <truly nitty>
>
> The text says
>
>   Thanks to Mark Andrews for providing the helpful notes for
>   implementors provided in Appendix B.
>
>   The authors would like to specifically thank
>   …
>   Mark Andrews also provided the
>   helpful notes for implementors (https://www.ietf.org/mail-
>   archive/web/dnsop/current/msg18332.html) which we made into
>   Appendix B.
>
> Perhaps you intended to thank him twice?  No problem, just wondering.

Nope, edit fail. Fixed.



Thank you again for your comments. I've posted / am just about to post
a new version with them addressed / incorporated.

W

>
> —Sandy
>
>
>
>
>
>



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