Re: [DNSOP] Working Group Last Call

神明達哉 <jinmei@wide.ad.jp> Wed, 05 October 2016 18:30 UTC

Return-Path: <jinmei.tatuya@gmail.com>
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 68A241297D2 for <dnsop@ietfa.amsl.com>; Wed, 5 Oct 2016 11:30:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.001, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 f0oWUrsZVPsD for <dnsop@ietfa.amsl.com>; Wed, 5 Oct 2016 11:30:16 -0700 (PDT)
Received: from mail-qk0-x234.google.com (mail-qk0-x234.google.com [IPv6:2607:f8b0:400d:c09::234]) (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 BF3B21297BE for <dnsop@ietf.org>; Wed, 5 Oct 2016 11:30:11 -0700 (PDT)
Received: by mail-qk0-x234.google.com with SMTP id j129so218636011qkd.1 for <dnsop@ietf.org>; Wed, 05 Oct 2016 11:30:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=HoSadS4vYB4iKUGNyxNKZ0CwC9ip8nhTy9KvmJxW0ag=; b=JR4Y6rpfSooqTFGKs57oFCNkGT9mN+4kDfB8LH6s8Isk8O98E2yh4kb1XBItgOUXI8 H/cmgc49z4zusz427vEMBFGKrjP5q8IsJQexM2/el7E0zx1LfCL11mx9uVq9koccbLG6 NvdIUKjfzrXhXZXUnyOyEOGdgKhsp0r5eT3PnQBWi09DwofjeGaY5SkLldnBc/4WDhOW mEKredwy883XMOW0ZhDlrlhQ+gr3IqT5mGNNL6ISYy34hjF1cPhEjlBHLOMwB1t+vrMj JGwXh5fT9MQm/uNwQ5W5UKG/pwqu2LFowQR8OZOkVqCx8Os6/MnlgqSBiB+fndHD1k8p vQaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=HoSadS4vYB4iKUGNyxNKZ0CwC9ip8nhTy9KvmJxW0ag=; b=jlMUsR+eSVRPjpgPq/TU+9E5BULc5dcus6+VaXbjOC7RmOK8ZPRER8w1FlpFgFeyqu JXkGCSrBLleJIe2huwOA7KasEetNu9zxEt5j5NxMEmFOlMfzH2AawTM3bYS7W7xvKtxA /u4BJt9Gs8sHb4LaEh7iFCjPop3p9HJWoDdbuBse/35p+3IAqniTvjeahLkWN6HpI3oO /s1C6eOFxkzJ/XAYp3ev3nNLs87yxWrxlZrGpt7ytrSp9lfGN4CI6ANyzPgAnb4wI89c FUEU0vk9lIRroo1JUYquKqyS5OeNPdnKcVBvRtQ3SD07n5t4b/iWULUBeneWW3EAjqTD PsSg==
X-Gm-Message-State: AA6/9RmnZ3PP5Z6Hnd0U5d6RgpDpUBQYuUAMPTdkgnbfWNRs0+J0Gm70hacBeUeE8aLARh01MbB9VXMDQk09mg==
X-Received: by 10.55.76.207 with SMTP id z198mr10203622qka.194.1475692210900; Wed, 05 Oct 2016 11:30:10 -0700 (PDT)
MIME-Version: 1.0
Sender: jinmei.tatuya@gmail.com
Received: by 10.237.54.227 with HTTP; Wed, 5 Oct 2016 11:30:10 -0700 (PDT)
In-Reply-To: <CAHw9_iJDfKK3BPKw5vRc4MBJJELUceSWO4fp97gZjAuB3PZJNg@mail.gmail.com>
References: <40d5f4b1-3019-7f8a-ecc0-2f4d13e3eadf@gmail.com> <CAJE_bqeEBSrFaxEVGhKbt5LFqfe_QdoQQ1u4h9r03ZB3pJ4yzg@mail.gmail.com> <CAHw9_iJDfKK3BPKw5vRc4MBJJELUceSWO4fp97gZjAuB3PZJNg@mail.gmail.com>
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <jinmei@wide.ad.jp>
Date: Wed, 5 Oct 2016 11:30:10 -0700
X-Google-Sender-Auth: URWACXKE4QpI3Ld8Sfnp6vKcLFo
Message-ID: <CAJE_bqcK_pu4eWkk80ALOeAkCuTV_AoMisFY04q2P6nmZTmGvw@mail.gmail.com>
To: Warren Kumari <warren@kumari.net>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/qdwd5MRPymOD803aEcAAZmvGNcA>
Cc: Tim Wicinski <tjw.ietf@gmail.com>, dnsop <dnsop@ietf.org>
Subject: Re: [DNSOP] Working Group Last Call
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: Wed, 05 Oct 2016 18:30:21 -0000

At Tue, 4 Oct 2016 17:39:55 -0400,
Warren Kumari <warren@kumari.net> wrote:

> > - Section 3: this section also has an issue of "recursive resolver".
> >   Although it may not be as critical as other part of the draft since
> >   it's only used as an example scenario, it's probably better to not
> >   limit the role of resolver to avoid misleading.  Maybe "recursive
> >   resolver" is just changed to "validating resolver", and
> >   "authoritative server" is changed to, e.g., "external servers"
> >   (meaning either authoritative or or other recursive servers).
>
> DONE.
> I did some fix up - how do you like:
> "If a validating resolver gets a query for cat.example.com, it will
> query the example.com servers and will get back an NSEC (or NSEC3)
> record starting that there are no records between apple and elephant.
> The resolver then knows that cat.example.com does not exist; however,
> it does not use the fact that the proof covers a range (apple to
> elephant) to suppress queries for other labels that fall within this
> range. This means that if the validating resolver gets a query for
> ball.example.com (or dog.example.com) it will once again go off and
> query the example.com servers for these names."
>
> Does that cover it sufficiently? (and I think I now better understand
> your concern).

To be perfectly generic, "it will query the example.com servers" is
not always the case.  It (= validating resolver) might query another
intermediate resolver (often called a "forwarder") that performs
recursion.  By "external server" I tried to generalize the concept.

I'm not sure how we address the subtlety without being overly
verbose.  Perhaps we can note in the terminology section that this
draft generally describes (validating) resolvers as those performing
recursive resolution, but the proposal will also work for resolvers
that rely on other recursive (or "full service" if you love to use
this term) resolvers.  And then we can keep Section 3 as is (as of ver
02).

> > - Section 4
> >
> >    We believe this
> >    recommendation can be relaxed because lookups for the specific name
> >    could have come in during the normal negative cache time and so
> >    operators should have no expectation that an added name would work
> >    immediately.  We think that the TTL of the NSEC record is the
> >    authoritative statement of how quickly a name can start working
> >    within a zone.
> >
> >   I'm not necessarily opposed to this claim per se, but IMO it should
> >   provide some more careful justification.  [...]
>
> DONE
> I copied and pasted some text from Cheese Shop and also cleaned up
> this section somewhat.
> I think that I have now managed to successfully explain the reasoning,
> please let me know if you disagree / have suggested text.

Hmm, the new text in 03 doesn't seem to be so different from that of
02 on this point.  But this was actually what we reached as a
consensus I won't rehash it at this point.

> > - Section 5.2
> >
> >    Implementations SHOULD enable aggressive use of NSEC by default.
> >
> >   On a fresh re-read of the draft, I'm now not so sure if this is
> >   clear enough and the requirement is reasonable.  First, does this
> >   also implies an implementation SHOULD implement aggressive use of
> >   NSEC?  Secondly, and especially if the answer to the first point is
> >   'yes', I'm not sure if SHOULD is reasonable.  Since this is just an
> >   optimization, it may be just up to the discretion of the
> >   implementor.
>
> Only implementations which want to support Aggressive NSEC should
> implement Aggressive NSEC. It's up to an implementer to decide if they
> want to have this feature or not.
> I've tried to clarify this with: "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."

Works for me.

> > - Section 9
> >
> >    Aggressive use of NSEC / NSEC3 resource records without DNSSEC
> >    validation may cause security problems.  It is highly recommended to
> >    apply DNSSEC validation.
> >
> >   This paragraph is awkward.  I pointed this out several times, so I
> >   won't repeat it here - please refer to my previous comments.  One
> >   possibly new perspective is that this tries to cover cases where
> >   NSEC or NSEC3 is somehow cached before/without DNSSEC validation and
> >   note that such records shouldn't be used for the purpose of
> >   nsec-aggressiveuse.  If so, it might make some sense, but in that
> >   case it should be totally rephrased to avoid confusion or
> >   misleading.
>
> DONE.
> How is:
> "Aggressive use of NSEC / NSEC3 resource records without DNSSEC
> validation may create serious security issues, and so this technique
> requires DNSSEC validation."? I don't love it, additional suggestions
> or text welcomed.

To me the main point isn't address with this text.  I might be able to
offer alternative text, but can't we perhaps just remove these 2
sentences?  In a sense these talk about the obvious, and in other
sense it could be even harmful as it can be misleading.

--
JINMEI, Tatuya