[DNSOP] Questions on draft-ietf-dnsop-delegation-only

Ben Schwartz <bemasc@google.com> Wed, 29 July 2020 19:55 UTC

Return-Path: <bemasc@google.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 D059E3A0EA8 for <dnsop@ietfa.amsl.com>; Wed, 29 Jul 2020 12:55:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Status: No, score=-17.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, ENV_AND_HDR_SPF_MATCH=-0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=google.com
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 8NnlNR-RzqdW for <dnsop@ietfa.amsl.com>; Wed, 29 Jul 2020 12:55:03 -0700 (PDT)
Received: from mail-wr1-x431.google.com (mail-wr1-x431.google.com [IPv6:2a00:1450:4864:20::431]) (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 BAB263A0E95 for <dnsop@ietf.org>; Wed, 29 Jul 2020 12:55:02 -0700 (PDT)
Received: by mail-wr1-x431.google.com with SMTP id y3so22751674wrl.4 for <dnsop@ietf.org>; Wed, 29 Jul 2020 12:55:02 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=dpHdxK1FFgFVSnus3fN6rNzSj5O9Yz4YaXbE3uan+QU=; b=GXCFgYcakoeuAk3bx4EWZNcdBJWXj4eaTkmPzJXMMih/MGz2EKwxEMelD9Ey9eJJi0 NSPfW6qoojQW+aiF3fwgIV/nw/651uV09rlxL1Gk73kblzfxdBU2U5mK+kZcDq/JbN5L 6aXdgQ08ggoLYRA+KUpOvqNeMMWXBPbuyItvfSvzAswCm591/HPweYSCxOHlPYLhNbpM plTia67EvuZ9bYF9f6h++MTaL50G+e5sxg0ls7B2OrNZ2nT8N+PswViFzxDXcpEItAtU lhoJNnRgCwixTEY2FW5uelX37WvAi5Ce/jZg9KxlnBwJCUzS08E/yKQ9UU9d3M66pNxQ WXWA==
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=dpHdxK1FFgFVSnus3fN6rNzSj5O9Yz4YaXbE3uan+QU=; b=Igtq9KAYrsJzQvj2NA7EREgfNwdBCeluWUgE3juGO259y+6RhAnTqNlM7/Xv6SfG5J 0ZcOKg2SGu7z2GtXGmytI9kx/f8NFOjF66bkhZI/+q8LicVH/L/EKBfmRHpF3by6dlge NYS93E4jd7wpUlT/3YeylIJmsSoy8BhWnHAgnB7UG+XifaWPGF/0wY/JS9A4T4pclJ3k RJE9Z3yfyBF631JSgj3vDHxCobA5gqQMGjRsNYAGDlH0Wdtro+uzleGy7AOvrbtw6zYG 6O1OFKuwbapH2nPcPcEovUEvVBtXmOftndvaJwGxVyi2OXpPCb2ijrzwgizQq5SNtMS0 NP+g==
X-Gm-Message-State: AOAM533dd0+ehaVRBonAs90cv2egapEHEc3QJfkYpiYXTQdNgCVEkE/M KNJLSE8h4KbKf6Mdn1T5hex1SChMtb2kVwFk4I10ozwuVHA=
X-Google-Smtp-Source: ABdhPJxAtrvNeYLUwWKOpACzznL63GGk1cLGWuY+98/anzklkbOtDuL7LhfijvSl78WT4SPCXZT9Dj92jh5qrZAE6kQ=
X-Received: by 2002:adf:e486:: with SMTP id i6mr100476wrm.258.1596052500383; Wed, 29 Jul 2020 12:55:00 -0700 (PDT)
MIME-Version: 1.0
From: Ben Schwartz <bemasc@google.com>
Date: Wed, 29 Jul 2020 15:54:49 -0400
Message-ID: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com>
To: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg="sha-256"; boundary="0000000000005df4b005ab99eec7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/cnycGIxdXzNh1Os_qH-CrUQC0aY>
Subject: [DNSOP] Questions on draft-ietf-dnsop-delegation-only
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
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, 29 Jul 2020 19:55:05 -0000

I'm generally supportive of draft-ietf-dnsop-delegation-only, but I want to
make sure that the draft isn't overstating the achievable benefits.  To
that end, I have some questions about the text of the -01 draft.

(I recognize that these are issues I've raised before, but I still haven't
gotten answers that I understand.)

Assuming the claims are correct, I think they need some clarifications for
naive readers like myself (and possibly deduplication, since some claims
are repeated in different sections).

>   Exposing such targeted attacks requires a transparency audit
>   infrastructure similar to what is deployed for PKIX ([RFC6962]).
>   However, a DNSSEC version would need to log significantly more data,
>   as all signed DNS data used by a DNSKEY must be recorded in order to
>   prove that data signed by a parent zone's DNSKEY was out of expected
>   policy.  The very distributed nature of the DNS combined with the
>   typically frequent zone resigning rate makes such transparency logs
>   prohibitively expensive and nearly impossible to operate.

How does this draft alter that cost?  For delegation-only zones that are in
compliance, it seems like the cost is not changed.  Presumably violations
will be rare, so they won't contribute significantly to the cost.

>   Additionally, it would require zone owners to expose all their zone
>   data to any public log operators, thereby introducing privacy
>   implications and exposing all relevant DNS data to a public archive.

I don't understand how this flag would alter that exposure.  If my zone is
already delegation-only, how does adding this flag improve privacy?

>   At the time of this writing, the list of entries in the
>   public suffix list contains over 8800 entries as well, with 73 wild-
>   card entries (prefixed with a "*") indicating that all of their
>   (unknown number of) children are public registration points.  In the
>   absence of an interoperable mechanism (like this draft provides), it
>   is infeasible that a validating resolver or auditing log could know
>   which of these zones are delegation-only without individual policy
>   statements from each of them.

Marking a zone delegation-only doesn't imply that it is suitable for
logging, so wouldn't participation in any logging scheme require an
individual policy statement anyway?

>   Finally, a DELEGATION_ONLY flagged DNSKEY for
>   the root zone cannot be overridden easily, as it would require a
>   trust anchor update in all validating resolvers.

The preceding sentences deal with the lingering "false child key" problem,
which still applies here, so I don't understand the relevance of this

I also had some thoughts on the Security Considerations:

>   Care should be taken by resolvers to not
>   unnecessarily empty their cache.  This is specifically important for
>   roaming clients that re-connect frequently to different wireless or
>   mobile data networks.

I believe this advice is counter to best practices for mobile clients for
both performance and privacy reasons.  See e.g. http://dnscookie.com/.

Also, I think it's worth mentioning that "delegation-only" zones can still
deny the existence of a DS for the child (if the child was signed to begin
with), and then generate deep unsigned records for the child.  This limits
the direct impact of this flag to cases where DNSSEC is mandatory.
(Logging might be able to deter this attack, assuming NSEC records are

Ben Schwartz