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

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

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 1CE11130F63 for <dnsop@ietfa.amsl.com>; Thu, 12 Jul 2018 12:36:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.422
X-Spam-Status: No, score=-0.422 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, FROM_EXCESS_BASE64=0.979, HEADER_FROM_DIFFERENT_DOMAINS=0.25, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id mRCGiYtA1Des for <dnsop@ietfa.amsl.com>; Thu, 12 Jul 2018 12:36:39 -0700 (PDT)
Received: from mail-lj1-f177.google.com (mail-lj1-f177.google.com []) (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 A540A130EF9 for <dnsop@ietf.org>; Thu, 12 Jul 2018 12:36:38 -0700 (PDT)
Received: by mail-lj1-f177.google.com with SMTP id v9-v6so12521576ljk.4 for <dnsop@ietf.org>; Thu, 12 Jul 2018 12:36:38 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=peJtDj9zDfNJAw5HNTfobyBhOofUD/z0BKcQ56XFrs4=; b=tKNGgPzFPvlupNh6PLQdO2ilIKJ0nQRQbBNqijWer4vP1tNf3g+YkPCni8nUIm6Gz/ S9zmW8IqBxgeCcnLW9FjALKHUiRgq5XYWVlGqwNxOYLFNvGieKFXswoOJXlngFywLraT l8cxozrORgLav8JjuWB0nwjCqcpS5dkPklsFH67mxRQm7TePlWDFTeA+7gx9qeEdxM/c cuipCRCGT/coZ2vJivJ5JyH5L2ZS1LnD9ojzd7JmOjMX3b8qRB5sKp5zaTevSDF9+hph U0tgm0EVyqLd8c/0uGkmLOijfpcrWTTCaIaz2ebwHjKihQ7LI/93OjN6LK5SX9jcvs4l FXVw==
X-Gm-Message-State: AOUpUlH4MfLZbAnBGc0YBbpCbG5MY/nvCSN/H1xGOlX8CW975paPEIQj SRmazVQdHNZASQTxDsHoWmJ+mKdaUTrwgFXynfToVcIu
X-Google-Smtp-Source: AAOMgpdN1cOgInoLfjtVwvNKWWJTdFGiuNnmMEEoxjTVGJFPEIKkhrMZ+n72WscN9cIQhNqm6XqHVnrIlz/YGo8Arv8=
X-Received: by 2002:a2e:4951:: with SMTP id b17-v6mr1356571ljd.67.1531424196584; Thu, 12 Jul 2018 12:36:36 -0700 (PDT)
MIME-Version: 1.0
From: =?UTF-8?B?56We5piO6YGU5ZOJ?= <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
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Thu, 12 Jul 2018 19:36:41 -0000

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

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