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

Ben Schwartz <bemasc@google.com> Thu, 30 July 2020 18:17 UTC

Return-Path: <bemasc@google.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 E254C3A10D4 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 11:17:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.599
X-Spam-Level:
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 ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7PRTUG6on3A9 for <dnsop@ietfa.amsl.com>; Thu, 30 Jul 2020 11:17:08 -0700 (PDT)
Received: from mail-wm1-x32e.google.com (mail-wm1-x32e.google.com [IPv6:2a00:1450:4864:20::32e]) (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 9C3DD3A10D2 for <dnsop@ietf.org>; Thu, 30 Jul 2020 11:17:07 -0700 (PDT)
Received: by mail-wm1-x32e.google.com with SMTP id p14so6540287wmg.1 for <dnsop@ietf.org>; Thu, 30 Jul 2020 11:17:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rv9AvhKogl1FYfoNR0LK/NEMw6vWhNN3li2l8S5w4tc=; b=nkVzhPw+M6WRPLZO1NkzdAqugTFzx0PuStuvtkq3y0+8M3mlLA6USimLIeTl1/A5SO lcq02EvwmlNsg8iDaZN/rWayZlMHhskQvNse8StQzngpVpEbV6m7DFs6NsG8FukrPX2k MlEVZu903jFBGnVLNBTD1GDQuYQfnZdST93X+uhT6zeKg0okBxVHtNJl5sCI28p0u4/d 3cplKjg6e2zFQf8Xl4gSGyGk/6a4Ms+iz0RZc1zGNTeZCw/WaValh4zTtp3piYRTGSHA PHomE7FMEu8oEPRUZGfPtj2Gwzrm91sOWTj0IY0y9Z3HtOnfXOvVbiRgz6Syt126leWT 81gw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rv9AvhKogl1FYfoNR0LK/NEMw6vWhNN3li2l8S5w4tc=; b=osaJbEcd3/T3Thrhk04m7jXvZ6cBU5dxJTP6ji4xIdgepbIRCde4vv3/KAnSLprgYg c9XzwJs5cEfAX1UKx5BlGqSLXhOw2N5W1e+89Lgo0fTtd28HIazWlqYfaEH1EE5GU9zg Uf8Rs97ox03jMGBOYewlhcHlOyHPnndjpfavVWewtR+4XtU5KjHGUBHba+OOa1AmsXPr Gv06q6kJ5a4QVGn5WqFYj5dOmcz/VqAiSxDlDNzdsfGgLkH2Ur9y/6AOOLBXG65vW+O7 cDLuR+SOVXKoSoul18xBqrqWjXOvZ2/2rVu8Jg+jCXdkkuUNpvDJHKEm4ogqn80a8/In 2BxQ==
X-Gm-Message-State: AOAM5318iN5WOBNsWB7rdE+dOh5cga17f60Y2q3xwGxY/HYUzTdp4GCq 09EfTJmFDjUIlLnmGAihamhaFH0ugf0SNxn3CFaGuS7y
X-Google-Smtp-Source: ABdhPJxxE9s8JnbrvDbt9OCNTpdYoDCfb8Jykm4arog7sol1szeOvgwb/UnI2xWIAaL3v2yDO02UglN3qzboZwsTFN0=
X-Received: by 2002:a1c:4183:: with SMTP id o125mr413712wma.101.1596133025520; Thu, 30 Jul 2020 11:17:05 -0700 (PDT)
MIME-Version: 1.0
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <05f9f7ce-1bb7-b195-1be5-4db4c13b3145@nic.cz> <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca>
In-Reply-To: <alpine.LRH.2.23.451.2007301253530.416340@bofh.nohats.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Thu, 30 Jul 2020 14:16:53 -0400
Message-ID: <CAHbrMsDoYO_hsuCjLeg9pwut_dB703uJ6tgGV0NDq_5sSUWJwA@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: =?UTF-8?B?UGV0ciDFoHBhxI1law==?= <petr.spacek@nic.cz>, dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="00000000000007efc505abacae4c"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/FbO5szIG0j11iBt9V9HvWe9Lx6U>
Subject: Re: [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: Thu, 30 Jul 2020 18:17:11 -0000

On Thu, Jul 30, 2020 at 1:21 PM Paul Wouters <paul@nohats.ca> wrote:

> On Thu, 30 Jul 2020, Petr Špaček wrote:
>
> > It is hard to see what benefits draft-ietf-dnsop-delegation-only brings
> without having description of "DNSSEC Trasparency" mechanism available.
>
> I do not believe that is correct. The first and foremost purpose is for
> the bit to signal the parent zone's behaviour in a public way that
> prevents targeted / coerced attacks from the parent.


I would love to see some more description of these attacks in the draft.
Does the targeted attack still apply if the recursive resolver does QNAME
minimization?

>From the current text, I'm having trouble understanding why it matters
whether the attacker has to generate a fake child zone or not (in the
absence of transparency).

This allows
> policy violations to be rejected even if these violating DNS answers
> are DNSSEC signed.
>
> Secondary, it eases the transparency logging. If it is clearer for
> us to leave out the DNSSEC Transparency parts, that can certainly
> be done, but I will try to provide text to Ben's and others to
> clarify this latter part.
>
> > On 29. 07. 20 21:54, Ben Schwartz wrote:
>
> >>>    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.
>
> You can only be a "delegation-only zone in compliance" if you publish
> this new DNSKEY flag. Without this flag there is no way to know the
> zone's policy.


My "null hypothesis" throughout is that

1. zone owners can simply tell me their delegation policy if I email them
to ask, and
2. participation in a logging scheme would require manual review and
approval anyway, because delegation-only zones could still be inappropriate
to log, either because they have privacy concerns or because they would
spam the logs.

If we can safely log any zone that puts up this flag, without further
review, that would certainly make for a stronger case.  Perhaps we can make
logging opt-in part of the flag definition?  Or perhaps we can signal it by
the use of NSEC instead of NSEC3?

This is what is often described as the Public Suffix
> list/problem.
>

The Public Suffix List has little to do with delegation, and many of the
listed suffixes are not zone cuts at all (e.g. github.io).  Membership in
the PSL would be entirely independent from the DELEGATION_ONLY flag (unless
DELEGATION_ONLY is defined to have additional semantics for HTTP!).
However, I agree that it is an example of the kind of non-technical, human
process that I am describing, and would have significant overlap with
delegation-only zones.

One you know a zone is delegation only, the only way this zone can still
> try to violate its own policy is to replace the child delegation with
> its own. Therefor, you only need to log DS records that will show you

there is a child zone change. And resolvers can drop any Answers DNSSEC
> signed outside the apex as bogus. Therefor, the parent won't even try
> to do this and we dont have to log all its queries.
>

But if the parent zone is delegation-only, then there won't be anything
else to log except in case of violation, so these two logs are normally the
same size.

Without this bit, even if we know ".ca" is defacto a delegation only
> zone, we have no mechanism to drop records violating this policy without
> maintaining a public suffix list type within the resolver or using some
> RBL type queries to more dynamically determine the delegation-only
> aspect. So now we need to log things like _443._tcp.nohats.ca. IN TLSA
> records if signed by something higher than nohats.ca because we can
> no longer declare such records as "harmlessly dropped as bogus" and
> we simply cannot tell if the record is legitimately signed or not.
>

But how would such a signature come to exist, if ".ca" is a defacto
delegation-only zone?


> >>>    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?
>
> Your zone is not "delegation only" if you have no automated way of
> declaring it as such that is accepted by DNS resolvers all over the
> world. See Public Suffix issues.
>
> >>>    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?
>
> Logging is not done by the publishers (zone owner) like in CT. Logging
> would be done by DNS resolvers in some privacy preserving shared method.
>

The draft says that universal logging "would require zone owners to expose
all their zone data ... thereby introducing privacy implications".  This
seems to apply whether or not the zone is delegation-only, so DNS resolvers
would be violating this proposed privacy principle unless the zone somehow
indicates that it opts in to logging.

...

> >> 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/.
>
> Performance and privacy cannot always go hand in hand together. As for
> privacy, I don't understand your argument.
>
...

> On an empty DNS cache, I'm quite literally broadcasting the largest DNS
> fingerprint possible to identify my. My only change at hiding is to have
> a local DNS cache.


If you move IP addresses without wiping your DNS cache, your cached DNS
entries become a supercookie by which a distant server can reidentify you
across the network.  As such, I've been told that the best practice for
privacy is to bind the cache to a single interface and IP.  I would love to
see a draft on this topic, especially if you think this is actually not the
best behavior for privacy.

The last thing I care about is 20ms speedup for some
> web page content - the ones who care about those 20ms are the ad auction
> participants, not me.
>

In case it isn't clear, the concern here is about incorrect network
localization of DNS responses.  This is particularly important when using
CDN nodes that are _inside_ an ISP, and are intended for (or perhaps even
restricted to) serving that ISP's customers.  However, it's true that this
is primarily about small performance gains.

>> 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
> logged.)
>
> No they cannot generate "deep unsigned records". Their zone is signed,
> so if they are not adding a zone cut / delegation, then they have to sign
> it or else DNSSEC validating resolvers will drop those queries as bogus
> (missing RRSIG).
>
> Yes they can deny the existence of a child, but that too needs a
> signed record of non-existence (NSEC or NSEC3) which would be logged by
> transparancy clients logging DS or proof of non-existence of DS.
>

Yes, as I noted, this mechanism can deter this attack, but it cannot
prevent it.

If you are talking about TLD's that are not dnssec signed


No, I mean signed parents.

...

> The power to change A/AAAA is not what anyone is really trying
> to prevent. The prevention is mostly for records with public keys of
> fingerprints, such as TLSA, SSHFP, IPSECKEY, eSNI and what not.
>

Yes, but nothing in the draft mentions this ... nor its converse, that the
draft only prevents targeted attacks in use cases that already mandate
DNSSEC.