Re: [Doh] on blackholing resolver-associated-doh.arpa and resolver-associated-doh.arpa

Ted Hardie <ted.ietf@gmail.com> Tue, 26 March 2019 15:32 UTC

Return-Path: <ted.ietf@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7AB1F1203CA for <doh@ietfa.amsl.com>; Tue, 26 Mar 2019 08:32:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.2
X-Spam-Level:
X-Spam-Status: No, score=-1.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_BOUND_DIGITS_15=0.798, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cWucWuf-FPPb for <doh@ietfa.amsl.com>; Tue, 26 Mar 2019 08:32:27 -0700 (PDT)
Received: from mail-it1-x12f.google.com (mail-it1-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 9F0361203E9 for <doh@ietf.org>; Tue, 26 Mar 2019 08:31:58 -0700 (PDT)
Received: by mail-it1-x12f.google.com with SMTP id 139so20675607ita.4 for <doh@ietf.org>; Tue, 26 Mar 2019 08:31:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=zalkdL9cppTUksuu9vmMgFUTDM7JoaVKHwEw4gzwv60=; b=Z9cgFqguMk3UFe4H9830FZFRdCJkOj6AYZTxgVckapo3oS9QRK6nC7TBP61hHvoWdS uJcZVKIZVXEqkzuPIgdqCLkywamglKt/BPX0RXhVjLyNwLU/PRjP9vQbo6jCy/Rmbngv KGt3Aev0lbPioDAs2GpfCRMDHygC1B88ad/AJmnW1sswCVNPoUu4uwFiVTiPZel92zhH B4kBKnZK5vUHDbX08iBo9h+BlcS6k5uzXirKUflBwXMy7JrRIU4IgwvBHai6HXWoPUVn liCIDzO9l2bGNkNDjq76nVJpZTYKyE0EUcT17Bhud1cA+xDo8yrxxU8ouVrAZAD0NxXi y30g==
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=zalkdL9cppTUksuu9vmMgFUTDM7JoaVKHwEw4gzwv60=; b=JY9DGzquq3INBQZqhmh1OFyp3UAlC+/nYipkXskjAyGT/SiF+HSa+TBFvpn5d1Lg62 0iC6/7c+T29dI9MkLo8Zy5tjtArzSlSuM+PHAcpGfKA9JxA73QPBdW4Oj7CjbcvzwELH 7IGFPYv+WKPZclLrxCIMTxuqcmGRw50Ha+JttII+m8MM9Gtut0erGtjmKLPapiZKVruX MSpWys8b3cBqNpbrlUqvt43f1/1b/58ECPBKXlHo6OJxJqXHij/a8ZT57LmL2IzDERrv DzY0QiQ3H2FbznEIVhzQajxV0pXPo1N8AuHmGo7eRiWo9ZvbT/T8+q5rBWJUBJzLiqui yObQ==
X-Gm-Message-State: APjAAAXauNVC/nQpKIVuLUvnGh6kBwc2UdjdkhE7565NeO7wigrr8dOx TqCSwNjdPoAcVQqdZtV910tBj5d8PBoO047lW3U=
X-Google-Smtp-Source: APXvYqxZ7hljSuMyVH1j+pkXNem5LocN7nmxGWBj028rRA8gvE6pJzbkpqNyIT5Vw7doyJ9pOqNuDdIc0AbRzda8uHg=
X-Received: by 2002:a24:5f8c:: with SMTP id r134mr703047itb.110.1553614317686; Tue, 26 Mar 2019 08:31:57 -0700 (PDT)
MIME-Version: 1.0
References: <E064E7E9-0E00-4B3E-8841-59EB40B4EEDD@hopcount.ca>
In-Reply-To: <E064E7E9-0E00-4B3E-8841-59EB40B4EEDD@hopcount.ca>
From: Ted Hardie <ted.ietf@gmail.com>
Date: Tue, 26 Mar 2019 16:31:30 +0100
Message-ID: <CA+9kkMBCeecLFOk3eG6WzSdG9icBEme_G4hUxVXM=kuqfio+cw@mail.gmail.com>
To: Joe Abley <jabley@hopcount.ca>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000008612090585010566"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/097f00JGnSKZhxKweLw8wBMMWbc>
Subject: Re: [Doh] on blackholing resolver-associated-doh.arpa and resolver-associated-doh.arpa
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <doh.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/doh>, <mailto:doh-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/doh/>
List-Post: <mailto:doh@ietf.org>
List-Help: <mailto:doh-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/doh>, <mailto:doh-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Mar 2019 15:32:30 -0000

Hi Joe,

When I sent the text (as requested), I just grabbed a copy of the text
from  RFC 8375, Section 7.  That suggests pointing to 'blackhole-1.iana.org.'
and 'blackhole-2.iana.org.'  which the AS112 project augments.  The issue
that these were built to solve, a high load of queries to .arpa for queries
leaking into the zone, seems like it might apply to this special use name.

DNAME is theoretically possible instead, but the .arpa server operators
have historically been slow to take up the idea of using DNAME (they did
not agree for .home.arpa).  I have no objection to trying again, of course,
if that is preferred.

I agree that there is a possible issue here, and I would support
documenting it.  But since the basic trust model I'd suggest for a doh
server discovered this way is equivalent to "something scrawled on the wall
of a coffee shop", I think this situation (in which they are not recognized
locally as special use names, and the particular anycast AS112 server
answering the leaked query is an attacker) is pretty much par for a pretty
rough course.

Ted


On Tue, Mar 26, 2019 at 12:18 PM Joe Abley <jabley@hopcount.ca> wrote:

> Hi all,
>
> There was a suggestion at the microphone this morning in the Grand
> Ballroom that the resolver-associated-doh.arpa and
> resolver-associated-doh.arpa domains be "blackholed". The draft currently
> specifies that these MUST NOT be delegated from ARPA.
>
> The microphone queue was already cut off before I could ask more about
> what this means, but I think it's worth reminding the wg what blackhole
> generally means in this context of DNS names in and near ARPA, and how it
> can be implemented, since I think there is a security concern.
>
> RFC 7534 provides two mechanisms to blackhole DNS traffic: one uses DNAME
> (see RFC 7535) and the other uses a zone cut. The DNAME approach is
> technically compatible with the MUST NOT in the draft (since it's
> technically not a delegation but rather a redirection) but the direct
> delegation mechanism is not.
>
> In both cases, however, blackholing these domains would point their DNS
> resolution away from the authoritative servers that serve ARPA towards a
> loosely-coordinated set of AS112 servers.
>
> Anybody can operate an AS112 server; in fact, operators have in the past
> been actively encouraged to operate AS112 servers without any requirement
> for coordination. This has been considered a reasonable approach so long as
> the query data being sent to AS112 servers is recognised to be junk that
> only leaks by accident; since it's generally private network PTR query
> traffic the potential for exploitation by bad actors (malicious AS112 node
> operators) is arguably low.
>
> However, in the case of these doh resolver domains, there is the potential
> for a bad actor to respond with an unauthorised list of DoH URIs and steal
> the resolver traffic of a large array of end-users whose local (or
> configured) resolvers don't implement the mechanisms described in this
> draft. This would be a bit like DNS changer, but without the need to infect
> individual end-hosts..
>
> I think this a problem.
>
> I think (in contrast to the thought at the microphone) if we mention
> blackholing at all it ought to be of the form "don't ever do this because
> it would be bad for the following reasons".
>
>
> Joe
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>