[Doh] more generally on resolver-associated-doh.arpa and resolver-associated-doh.arpa

Joe Abley <jabley@hopcount.ca> Tue, 26 March 2019 13:26 UTC

Return-Path: <jabley@hopcount.ca>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 0C2A51202FC for <doh@ietfa.amsl.com>; Tue, 26 Mar 2019 06:26:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=hopcount.ca
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id bGcuOV4fZ4hG for <doh@ietfa.amsl.com>; Tue, 26 Mar 2019 06:26:00 -0700 (PDT)
Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (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 73B86120043 for <doh@ietf.org>; Tue, 26 Mar 2019 06:26:00 -0700 (PDT)
Received: by mail-wm1-x343.google.com with SMTP id y197so12931957wmd.0 for <doh@ietf.org>; Tue, 26 Mar 2019 06:26:00 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=hopcount.ca; s=google; h=from:mime-version:subject:date:references:to:in-reply-to:message-id; bh=Kf8vjETI6CFK8E2dIBBRwVhgvVVvoPi9tDBmHPbhb3I=; b=f5O6kZl1uDVL7bLi3yFUfbivKrMa3UCLFrpzRODUwFSpmpLwEUEENVRFBBzmquHYDU XDqL1t3V9mJtea1xukm6rB0hMNtJntsjKTXqMATpcYoE4Fv/yu407RKGPHCKAGSR2wsY 5EhSvBOHTNWtMb09bCQ7r+xh4rRiXgfzWTOTg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:date:references:to :in-reply-to:message-id; bh=Kf8vjETI6CFK8E2dIBBRwVhgvVVvoPi9tDBmHPbhb3I=; b=Rxwn40JakTNwzNi31ImnG9w2qQoz0kuDvlap70qJSUw2MJhihGr35yLq4xst5VzSG/ IiGKIwRou1+SKsseMjxqQUOAoV5BUDmacyEufoF6mBLFvgobSxk2uVHrF16+ViKuOLJp +UtVregpZdLdrW0PoRZhKZ6ZKGf7rcSidt4Bmy3nJ+9mGjbziv/Q58K0GnmUNCHycdvF 770qLNWE0u2N6yNOWR9Wu/xoBxZCbvZVTwj/D0fa1A2NZjTdA9QAWnsPg0pxFxGJdlZD jbz2tyy7w1Pgr6gn7S0b2o466AkfZ5zSGt9tAeFkGFtJK0ePrMsG8Lxh/MSq6Xb/tTdy NEIA==
X-Gm-Message-State: APjAAAUjgcjXE81QbhaZTW80tpgLOhKnhZZZr/+h2feFSs/nRi4lzb1P j8RCaFTawmY1s7nhCCNQgKZ08R/+V6cNCA==
X-Google-Smtp-Source: APXvYqyaf1k0YtHhvYtKhdtf603xfkH67jRr86TTja5UTdpy3o5ztI1G36xv66JjEdpCNb7f7+CuAQ==
X-Received: by 2002:a1c:39d7:: with SMTP id g206mr8273594wma.99.1553606758452; Tue, 26 Mar 2019 06:25:58 -0700 (PDT)
Received: from ?IPv6:2001:67c:1232:144:4541:7170:3836:e433? ([2001:67c:1232:144:4541:7170:3836:e433]) by smtp.gmail.com with ESMTPSA id r16sm8436219wrx.37.2019. for <doh@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 26 Mar 2019 06:25:57 -0700 (PDT)
From: Joe Abley <jabley@hopcount.ca>
Content-Type: multipart/signed; boundary="Apple-Mail=_C779F6B8-30E1-423A-9471-21E75CC7E63C"; protocol="application/pgp-signature"; micalg=pgp-sha1
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
Date: Tue, 26 Mar 2019 14:25:55 +0100
References: <E064E7E9-0E00-4B3E-8841-59EB40B4EEDD@hopcount.ca>
To: DoH WG <doh@ietf.org>
In-Reply-To: <E064E7E9-0E00-4B3E-8841-59EB40B4EEDD@hopcount.ca>
Message-Id: <4D942FED-E2F3-4A78-A1C5-3F72E013BF69@hopcount.ca>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/xKU7vWVfcsTTHZcOp0oHq3F9iMg>
Subject: [Doh] more generally on 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 13:26:08 -0000

Hi again,

I think my concerns about the "DoH Servers from DNS" mechanism  are wider than those about the blackhole suggestion that I mentioned earlier.

The  "DoH Servers from DNS" mechanism in general involves the retrieval of security-critical information for an end-user's application environment from the DNS in a way that necessarily precludes integrity protection by DNSSEC. A polluted cache, a compromised upstream forwarder or resolver, a man in the middle or just the accidental inheritance of a non-malicious upstream policy can divert all end-user resolver traffic to an unexpected location where the response policy is unknown.\

This is worse than DNSChanger or attacks on local DHCP infrastructure to divert resolver traffic since it has the potential to affect larger communities of end-users without the hurdle of local network or end-host compromise.

Any network that doesn't provision these domains on their local resolvers is hence vulnerable. If successful the impact of such an attack would be difficult to assess by the network operator since of course the query traffic is at that point obscured, being carried as DoH.

Architecturally, I think this mechanism is vulnerable by default, which is a poor security posture. It's a challenge to detect the attack and it's also challenging to defend against (e.g. in the case that an end-user doesn't start the discovery from a local resolver).


On 26 Mar 2019, at 12:17, 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