[DNSOP] comments on draft-pwouters-powerbind-01

神明達哉 <jinmei@wide.ad.jp> Thu, 12 July 2018 19:36 UTC

MIME-Version: 1.0
From: 神明達哉 <jinmei@wide.ad.jp>
Date: Thu, 12 Jul 2018 12:36:25 -0700
Message-ID: <CAJE_bqccJL65kOHKrGcVBYVGCv9qnRaPqvXeXARNS3q4SxoJdA@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/KnQ4eFmoH6QPM3Ru-AKpTtlvOrI>
Subject: [DNSOP] comments on draft-pwouters-powerbind-01
Precedence: list

I don't have a strong reason for opposing the proposal, but, frankly,
the need for this wasn't clear to me just by reading the draft.  I see
the potential problems with evil parents, but the draft didn't
convince me that it's an important and critical enough to justify a
new protocol extension (which made me recall the camel discussion),
not least because if the parent is malicious in the DNS then all bets
are off already.  If there's actually a consensus that this is an
important problem to solve, I wouldn't challenge that.  But it would
help newer/future readers if this doc explains the need more
specifically and in more detail.

It's also not clear how effective this is against the evil parent
tweaking the delegation (changing NS, e.g).  The draft seems to
try to address this point in a few places:

   [...] However, both
   of these actions cannot be hidden, thus exposing such malicious
   behavior when combined with public transparency logs.
[...]
   Replacing the NS and DS records of a child zone can still be done in
   a targetted attack mode, but these events are something that can be
   easilly tracked by a transparency infrastructure similar to what is
   now in use for the WebPKI using [RFC6962](bis).

but I was not sure why we can't also do this for the "deep link state"
problem (replacing a delegation with a parent's authoritative
record).  That's probably because I don't know much about the tracking
"by a transparency infrastructure".  In that case it might help if it
explains it in more detail.

I have a few more specific comments:

- I'd suggest making the requirement to validator implementations more
  explicitly:

   [...] if any such signed data is encountered by validating
   resolvers, that this data should be interpreted as BOGUS.

  Probably in a separate section like "Validator Behavior" rather than
  in Introduction, and maybe with an RFC2119 keyword.

- Section 3

   [...]  For example, the DNSSEC root key
   could ignore the NS records for ".org" and "example.org" and could
   place a record "www.example.org" directly into its own zone, with a

  "the DNSSEC root key could ignore..." doesn't make much sense to
  me.  Does this perhaps mean "the root zone could ignore..."?

- Section 4

   hierarchy.  This commits a parent in the DNS hierarchy to only sign
   NS and DS records (i.e. all non-glue, delegation records) for its
   child zones.

  Should this be "NSEC(3) and DS records"?

--
JINMEI, Tatuya

[DNSOP] comments on draft-pwouters-powerbind-01 神明達哉