Re: [Doh] Mozilla's plans re: DoH

Brian Dickson <> Wed, 27 March 2019 17:34 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2264F12000F for <>; Wed, 27 Mar 2019 10:34:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id yqdCV-gSdHf5 for <>; Wed, 27 Mar 2019 10:34:38 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::830]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 239411202AB for <>; Wed, 27 Mar 2019 10:34:37 -0700 (PDT)
Received: by with SMTP id d13so15143825qth.5 for <>; Wed, 27 Mar 2019 10:34:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=YRuDPbtse60Gfbp6r++idtnTOCE0Nae1m+EPw7Hfl3g=; b=IX3YPrc9habWokUsEFjpO4flNcqz6BJkrfcgEMXVaucBBU35nZBGZMdtRPbkYJI1gz f2s7VK63++rP+SCIfSdJRx/tkn5LMH0jOdXjyjoG03gsMcgjxzrAflPwqnG/van3A2RC ir5vOHCtOYTUTm3D+T/lLtXqRRvNjEDG/xV1OIGTyK7UqoXiz+XYCJjW9AvIt+9CECUL pG2gSTS5ajE0jrKprn9wCosaU2b/0KjzAyWJh/iXW+6+DCsJ6mynbAZfwmE7Pvp3VQ+z Ru7eRvRtiOfxVRfv9awzRSJoz6Hg3lavCy5Ow8Kr50Es088/5k6E1IS2rMovZhhUyKS/ r+kQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=YRuDPbtse60Gfbp6r++idtnTOCE0Nae1m+EPw7Hfl3g=; b=GWCCjOWxfjR6gw1M5pGJU31X8Mnbvw61lkGQWMKBDQ91BDa0BUfcyZ4bwiv4KmGFgm dMXJoC1qY8zv1Nh8glhsYdeqJKnP3+XBPxcUBFYn0ums1+9IY5sFOfY5AuNXdg1D04gl XxHjvyERlLwBq/P00m+7aJrKCxC5H/IOqsgOnesLkNVrVWbL5Q9ZIP50dtKKM+qkAhdm CgGRO4FdZ5IOQpVYqQruSwFS7oEgEAwtFQ6PQWlMEhgYaJss1wADOZiv5dSdh1BeWP9f JogICE9jEVKvuPVitFbwztHTfoInJ9LihcVPZ/dfALVJTgUN1ePdXUEjFqHoEQwYAGA/ bjsQ==
X-Gm-Message-State: APjAAAXaEyZnupJ2u6deBJPISts8k56KOSjm7gBAH9RKVyg98mA+ykXe Gw7sC+mpqyZi/Jt+d6heTJPTWkYIoeBbTrUXOTNBmTzl
X-Google-Smtp-Source: APXvYqw1Lw4YqvTDsts3tJBLhI62mem404TB01greIaiLV8/z/BePv4gSaLkboRvnfpieD6Aw+vuWSU83/oyRKBWRGA=
X-Received: by 2002:ac8:2d62:: with SMTP id o31mr11615216qta.370.1553708076278; Wed, 27 Mar 2019 10:34:36 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Wed, 27 Mar 2019 18:34:24 +0100
Message-ID: <>
To: Eric Rescorla <>
Cc: Tony Finch <>, DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000f8a6ea058516d909"
Archived-At: <>
Subject: Re: [Doh] Mozilla's plans re: DoH
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 27 Mar 2019 17:34:41 -0000

On Wed, Mar 27, 2019 at 5:57 PM Eric Rescorla <> wrote:

> On Wed, Mar 27, 2019 at 9:32 AM Tony Finch <> wrote:
>> Eric Rescorla <> wrote:
> > However, there are two more restricted cases in which we do think some
>> > network control of the resolver is reasonable.
>> What about allowing Firefox users to access private / internal domain
>> names?
> If a name doesn't resolve with DoH, we fall back to the system resolver.
> This doesn't work properly when the same name is available on the public
> DNS but pointing to a different location. As I alluded to in my email,
> we're still working out how to deal with this split horizon scenario.
I think there are data leakage and enterprise-specific issues, above and
beyond this, but I think there are ways to limit that, and identify the
split horizon existence:

If you do QNAME minimization and compare the delegations returned from the
system resolver and DoH server, if they don't have identical results, that
should point to the need to use the system resolver.

I can't think of reasons why they would differ except for split-horizon,
and possibly geo-ip stuff.

Non-split-horizon stuff follows:

I'd like to suggest other tests for determining whether using a public
resolver might be contrary to network policy, and thus be indicative of a
need for explicit user approval (opt-in).

   - Make connection attempts to the public resolver's IP address on UDP
   port 53, TCP port 53, and TCP port 853 (DoT).
   - Success on any of those could be interpreted as that public resolver
   being permitted by network policy.
   - Failure on all of those should be interpreted as that public resolver
   not being permitted by network policy.
   - I would also like to suggest adding a standardized DoH-only port,
   where the DoH-only port is used when policy appears to permit access to the
   third party resolver.
   - And finally, I would humbly suggest that the DoH "shared" 443 (HTTPS)
   port be used only with explicit user permission, and only when none of the
   above ports are accessible, i.e. "dissident mode".

(IMHO, dissident mode should also engage, or require the user to have
previously engage, whatever the specific browser calls its privacy mode,
e.g. "incognito", "private", etc., so as to minimize any residual risk to

There are host/network security reasons about why "DoH to third party, on
by default" is a riskier choice, or where the mechanisms of enabling DoH to
third party locations are easily accessible.
Malware C&C communication, and malware data exfiltration over DNS, are
host-specific concerns, whereby malware might take advantage of encrypted
DNS to offsite providers, by accessing the browser as a DNS vector.
Even if it doesn't raise the bar that much, taking it out of the realm of
"trivial" (i.e. requiring some activity on the part of malware to enable
DoH) would be preferable.