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

Ben Schwartz <bemasc@google.com> Mon, 22 February 2021 15:30 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 371A33A0597 for <dnsop@ietfa.amsl.com>; Mon, 22 Feb 2021 07:30:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -17.598
X-Spam-Level:
X-Spam-Status: No, score=-17.598 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, RCVD_IN_DNSWL_BLOCKED=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 e6YWr_0bAAm5 for <dnsop@ietfa.amsl.com>; Mon, 22 Feb 2021 07:30:54 -0800 (PST)
Received: from mail-il1-x12f.google.com (mail-il1-x12f.google.com [IPv6:2607:f8b0:4864:20::12f]) (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 098DA3A05AC for <dnsop@ietf.org>; Mon, 22 Feb 2021 07:30:53 -0800 (PST)
Received: by mail-il1-x12f.google.com with SMTP id q9so11154474ilo.1 for <dnsop@ietf.org>; Mon, 22 Feb 2021 07:30:53 -0800 (PST)
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=+7n1XdisTQ7UCCOhd3/bhML/HEunV1dwjnuUsvhnmzM=; b=IGmaW/ANpAgqdpIbq5rnHazn1gwv/Ttpb3BWpPIOgCNzIrZoc744T0Bk6hgLDJWobd HVK6UQcI0swMfQRlhufixmgBd/q4xF7xBZdUtJt+kTxE55g/RsJC6dnxh3fzSJ/+9nAU 1/l7C7QRV8GQYV8JV1dbc1TKY4I9cA4nVQQBx0xUJPBA1HKqGA+zn0vYt25lLBFHWa39 Sr/fA9uHW5iov8FxrShhB2qCJK6U1o/VJoIU6nV2Gxct+XUPTiWYFFstuy5Zbk9cfmxb UVAp/q784b3MrYyynJpBc0v3XEWnSb71h+g42pBkpZkfbEz6HqxB2xYq3nfKv9JTLmbZ 54uA==
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=+7n1XdisTQ7UCCOhd3/bhML/HEunV1dwjnuUsvhnmzM=; b=sfnGDOqY+hrTHEMeJcclU/vb+6d6qnGU+P7ickmScJ7kI8W1m7+LfN58O/XsXVZvE8 0CXr+i7+4Tt3zEh41Ewqw5KpHHo8Dw0mMfTa5O4eHhsdHTt2kTOBfm7JS1QY4XUwZE/j KrmV+OWPhF5Ck4RF03+tzHnwk+PRIlTEVsyL5RErrPswWd5luqqZMYUM+EQ5hsXLLtnw Nrx0HNyFI3Mkh0PQD0kYgqJhLiF2Hgn+UMI+zL5qLCQJiHOu+tMy5WLZOSpNF0dPoZFL +ce4e4ld33fhWupIVdfygJNDu1Ln8I5v0pfedCSxu2O+QEqJjTLHnwFRSyPlZ2ebsjhS kStw==
X-Gm-Message-State: AOAM532v2Cq9193+A1/wBuZf0MCNguP11FjbRgkByJnnOni40aSPBOSX YP2tmFtwpFjel/l/RG7eM4iyNuLOgN3FcMnH5egzGg==
X-Google-Smtp-Source: ABdhPJxTG7r9RWjS5CCgf4GCSy5PwlTdBSLDvjNF6acpGqZZOZZWc0wdXwDv/OYtO7E/XB+peN2J3rvrLqE6dFrZUHM=
X-Received: by 2002:a92:cccb:: with SMTP id u11mr15349348ilq.44.1614007852962; Mon, 22 Feb 2021 07:30:52 -0800 (PST)
MIME-Version: 1.0
References: <CAHbrMsDWR0Yf_66f7g6sYm5Wk5vg9avGnLLT2sqezHzJzK4qJw@mail.gmail.com> <733b311-c6b8-c3eb-10e-5a3459836f@nohats.ca>
In-Reply-To: <733b311-c6b8-c3eb-10e-5a3459836f@nohats.ca>
From: Ben Schwartz <bemasc@google.com>
Date: Mon, 22 Feb 2021 10:30:38 -0500
Message-ID: <CAHbrMsCu3N6XwgS9qu4x7ybNT5kL4ThGR1kTQribskUs7y4G5g@mail.gmail.com>
To: Paul Wouters <paul@nohats.ca>
Cc: dnsop <dnsop@ietf.org>
Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-256; boundary="000000000000c4f93b05bbee7cd7"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/Zc8slldK7Y-ZsYEaCyB4b58y0Q4>
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: Mon, 22 Feb 2021 15:30:56 -0000

Thanks for these replies, and updates, Paul.

On Sun, Feb 21, 2021 at 5:01 PM Paul Wouters <paul@nohats.ca> wrote:
 ...

> It might be that the occurance of this deep signed data is rare, but
> without the delegation-only flag, you cannot determine if such deep
> signed data is legitimate or not. That is what the delegation-only flag
> indicates.
>
...

> > Presumably violations will be rare, so they won't contribute
> significantly to the cost.
>
> I don't know how rare this is, but for example if it became known that
> this logging was happening (due to not having delegation-only) then
> atttackers could spam the DNS transparency log with deep signed data
> that would have to be logged.


I'm not sure I agree.  For example, if a zone puts up a TXT record that
says "I promise to be delegation-only except in very unusual
circumstances", then a log could collect up to one deep RRSet (in addition
to all shallow DS and NSEC RRSets) for each child zone.  Any single
unexpected RRSet within a child zone is cause for concern for that child,
so there's really no need to log more than one RRSet per child for policy
enforcement.  That means the benefit to logs from DELEGATION_ONLY, as
opposed to "I am delegation only", is a factor O(1) _only for policy
violations_.  If the vast majority of the log is non-violating, the
difference in cost is a rounding error.  (If a large fraction of the
parent's log is violations, the log can impose a rate-limit and declare the
parent hopelessly violating.)

In other words, when the draft says:

> all signed DNS data signed by a DNSKEY must be recorded in order
> to prove that data signed by a parent zone's DNSKEY was out of
> expected policy.

This is not true for a delegation-only policy (or a nearly-delegation-only
policy), and that's the only policy that can be protected by the flag.

Attackers could also try to hide and
> seek via CNAMEs.


I don't see why it would be necessary to chase CNAMEs.  It should be enough
to log them, so the owner can be alerted that an unexpected record appeared
for their zone.

...

> > 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?
>
> DNS audit logs could decide to only log parents that are
> delegation-only.


They could, but they probably cannot simply log all zones that have the
flag.  It is trivial to spam the log from a delegation-only zone.  That
means log operators will still have to curate a list of zones to log (or
attempt to curate a list of zones _not_ to log, even as spammers move
around the namespace).

The reason I support this draft is because I think DELEGATION_ONLY
might work as a filter to identify logging-friendly zones when combined
with another pre-existing curated list, such as the TLDs or the PSL.
However, given the difficulty of making many TLDs purely delegation-only, I
think we might do better to define a flag that is used only by the log
operator.


> > 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/.
>
> I read up on that page but the information there is not very detailed. I
> _think_ that forgetting a cached entry before its TTL is up, would
> actually expire this dnscookie faster?


Yes, but the security considerations say _not_ to empty your cache.


> So you would become less
> trackable?
>

FWIW, I think the best practice is really to partition the DNS cache by
network interface.  That's not quite the same thing as "emptying" the cache
when switching between networks.  In principle, one could cross-check DS
records across cache partitions, even if the other cached records aren't
being used.

More broadly, I don't understand what a resolver is supposed to do on the
basis of records it has in cache, in order to detect an attack.  It seems
like more caching of DS records is just as likely to benefit the attacker,
since the false DS records can be cached just as well as the real ones.
Maybe this could be explained in more detail.