[Doh] DOH and Induced DNS

dagon <dagon@sudo.sh> Mon, 06 November 2017 17:07 UTC

Return-Path: <dagon@sudo.sh>
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 DBA8313FBB2 for <doh@ietfa.amsl.com>; Mon, 6 Nov 2017 09:07:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id Dvy3LGO1iDyb for <doh@ietfa.amsl.com>; Mon, 6 Nov 2017 09:07:51 -0800 (PST)
Received: from sudo.sh (hexakaideca.sudo.sh []) by ietfa.amsl.com (Postfix) with ESMTP id 4081513FB6E for <doh@ietf.org>; Mon, 6 Nov 2017 09:07:50 -0800 (PST)
Received: by sudo.sh (Postfix, from userid 1000) id 23BCA42BEA0; Mon, 6 Nov 2017 17:07:50 +0000 (UTC)
Date: Mon, 6 Nov 2017 17:07:50 +0000
From: dagon <dagon@sudo.sh>
To: doh@ietf.org
Message-ID: <20171106170750.GA24665@sudo.sh>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.5.23 (2014-03-12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/XQ3MruxwX-kfIrS9O1hGLkaF3nQ>
Subject: [Doh] DOH and Induced DNS
X-BeenThere: doh@ietf.org
X-Mailman-Version: 2.1.22
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: Mon, 06 Nov 2017 17:07:54 -0000

I might have missed something in the draft, but I worry about a misuse
of the DOH protocol.  To my knowledge, there exists no practical means
(outside of Flash, java applets, and special, limited DNS prefetch
circumstances) for web sites to provoke third-party clients into
performing mass (million+) DNS queries.  Indeed, for this reason,
projects such as the ICSI Netalyzr resort to signed applets, which
users must inspect and intentionally approve.  Outside of these
limited and off-by-default cases, HTML visits can't generate arbitrary
volumes of DNS queries. A handful, yes, but not DoS-levels.

But depending on how the DOH stubs are implemented, DNS traffic could
be induced through trivially crafted javascript.  For example, if
GET/POST primitives are all that's needed, javascript and 'document
write' calls can generate random child label queries towards a target
zone, e.g. repeated GETs for the encoding of "${UNIX_EPOCH}.\
victimzone.example.com". Instead of doing a handful of DNS lookups
(mostly prefetch), a web visitor could perform thousands or millions
of queries.

Consider these scenarios: could one purchase ads which induce DOH
queries non-stop?  Likewise, could one insert such content on popular
forums, troll links on popular sites, or otherwise attract enough
views to generate streams of repeated DOH queries from browsers?  A
few thousand web views would turn into millions of DNS queries.  At
present, misuse of HTML may trigger only a few dozen DNS prefetches,
if such resolution is not already turned off by the site (as it is
with https by default).

If these concerns are valid, and not a misreading of the draft, then I
offer these further comments and suggestions:

  a) UI proof-of-life?  Perhaps DOH resolution should be tied to
intentional user action, somehow known to the stubs, based on UIX
feedback, and perhaps presented as proof to the recursive and
authority through new EDNS fields.  I recognize this idea as bad and
unworkable, but offer it to suggest a larger goal: DOH queries should
reflect a browser user's express desires, and not the worst intentions
of the HTML/js author.

  b) Recursive BMPs?  I appreciate that the draft is only focused on
wire format issues.  But perhaps the DOH draft could address various
implementation choices, such as aggregate query limits, same-origin
limitations on DOH-based queries, and the like?  Some stub
implementation guidelines seem prudent.

  c) Header-only?  If we assume implementation mistakes will always
occur in DOH stubs and recursives, perhaps the wire encoding should
appear only in HTTP headers, since these are less easily manipulated
by crafted javascript and HTML.  At the same time, the headers are
presumably within reach of the stub.  Header fields seem more likely
to reflect browser user decisions, and not the HTML author's malicious
whims.  (At least the problem would only be as bad as DNS prefetch, in
terms of volume.)

  d) Recursion only?  I assume non-recursive queries would be rejected
by the DOH servers.  Should the protocol require this?  The same
question applies to invalid DNS messages.  Should DOH proxies/stubs
and recursives parse and validate the query, or may they naively put
the DNS message on the wire, "as is"?  Naive DOH recursive
implementations may do the latter, enabling a large range of proxied
DNS probes and protocol attacks.  (E.g., 0-day "query of death" packets
can be delivered via Tor, perhaps.  Maybe this is slightly more
convenient than spoofed UDP.)

  e) ECS opt-in?  I suspect all DOH enabled recursives will also be
ECS speakers.  A standard concerned with privacy might suggest that
DOH stubs be ECS-disabled (or scope 0) by default, since EDNS client
subnet payloads communicate information about the stub.

  At the least, DOH stubs must expose this switch to the user, even if
the vendor decides to use an opt-out approach.  A DOH stub without ECS
opt-outs effectively mandates subnet leaks to arbitrary websites,
unbalancing the privacy trade-off in RFC 7871.  Likewise, a malicious
website could discover the client IP, and deliver ALL the client
octets (and just not the network), to any DOH recursive, via crafted

                           *    *    *

DOH is a tectonic shift in how users produce DNS queries.  It
potentially lets any normal html author wield a "Great Cannon"
capability, https://citizenlab.ca/2015/04/chinas-great-cannon/
assuming crafted HTML/js can appear on enough browsers.  It further
raises interesting questions about user intention, DNS privacy, and
authority DDoS query flooding.  It greatly expands the attack surface
that malicious site operators can use, to either expose more user
information or exfiltrate data.  Absent firm DOH stub guidelines, and
DOH recursive best practices, it seems to expand the surveillance and
measurement capabilities of DNS researchers.

If I have not misunderstood the draft protocol, then hopefully my
suggestions point to practical solutions.

David Dagon
D970 6D9E E500 E877 B1E3  D3F8 5937 48DC 0FDC E717