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

Brian Dickson <> Thu, 28 March 2019 08:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 16604120450 for <>; Thu, 28 Mar 2019 01:27:14 -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 eGUk0U8V2fLu for <>; Thu, 28 Mar 2019 01:27:10 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::731]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4F13F12025F for <>; Thu, 28 Mar 2019 01:27:09 -0700 (PDT)
Received: by with SMTP id o129so11593963qke.8 for <>; Thu, 28 Mar 2019 01:27:09 -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=LFfeBdQijlfGSBu2KgZxfZqLfGVDkECaH3Va8f2zEJc=; b=Ky4aeMemL6G4qnhD8mldH/S6UUrlttpz3zOw9Od+RxRKE0L3va+6Ko7nx5rkjy3ILK mv4hjx66Wad430psha0qru0IUJGg4cr6oyJW6AEg1WqZRYPolxF21vO7IS3/XyQ1/5lv h3bgewrAiyp3MwHvw0XTGtbyro18c3BATogFF9Ecvw6iTs49lw9QUZ+Zid5ebXHCHss1 iT+SceoRyakzLE58mHpFlBLSETNSC+N9HxNmccEqykR/aC2sy91l3dowvgoWwMiviBaS mInOlwly7uPT9y87GHcEQAtUERTLalZGTXtHuSEI7b0jOjAyRfcVk0XMTBK7wsNkOLth cGnw==
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=LFfeBdQijlfGSBu2KgZxfZqLfGVDkECaH3Va8f2zEJc=; b=X2Lrpko1Z0SNnfRV9TiDPNtSA2SpXTwpHJQNIBpOblksYtHkNLT8bMlLM6aNAYFK/G e/GJaHz10hETOYj6G9OMsCGOrNC3glkIbJg/NGYQjF3W0NxBup6lj0HVjBK4Sx2gPEPD puv+FP8rItERE3oQR1l0V7MOaxZuhMuJ+n1ooQFNw7cBV+uEsLin2J88T/sSgtTyIah6 VfxfcJOgXpwcp2wz28RSPY8EHMN1K8l6M08oosx0W6pfseoy0giljQwslB13Z9yTjPbq p3Mg7z/1huA5axumgXFB9uJ2xwrnSByeNX1CFVKT1txZZOy+zT64+JuggiroiPZVnT5H HbUA==
X-Gm-Message-State: APjAAAUlkRJ+vP0O0w0UkY2mWH2OJjnAh1dlm/VjImN6XV/8dp9SxTpc qgzLrJosMO1fX4QzG8ma/IyKkrMb385g1uo4d9Yrfk7fVB8=
X-Google-Smtp-Source: APXvYqzpxhvfYqbUqSVKuP7fNu4PTe6NuwsT3fJb6j5KOVyqcO/iVWPvE1crTiCPfOPovU5Nf6wJQB1S68MEv6AZukc=
X-Received: by 2002:a37:d85:: with SMTP id 127mr32375774qkn.139.1553761628439; Thu, 28 Mar 2019 01:27:08 -0700 (PDT)
MIME-Version: 1.0
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
From: Brian Dickson <>
Date: Thu, 28 Mar 2019 09:26:54 +0100
Message-ID: <>
To: Stephen Farrell <>
Cc: DoH WG <>
Content-Type: multipart/alternative; boundary="000000000000edc7aa0585235148"
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: Thu, 28 Mar 2019 08:27:22 -0000

On Wed, Mar 27, 2019 at 11:46 PM Stephen Farrell <>

> I won't, sorry. I don't accept your proposed dichotomy as valid.

I would like to point out the consequences of your position.
I'm interested in your position on the various implications.
I don't want to put words in your mouth, but rather want you to use your
own words.

First question:
Consider the two following URIs, for use by a DoH client (e.g. in a
configured template):<NEW_PORT>/dns-query

(replace <NEW_PORT> with a dedicated-to-DoH port number assigned by IANA)

Let's presume the only server-side difference involved is the port the DoH
server listens to.
i.e. the DoH server listens only on 443, vs the DoH server listens on both
443 and NEW_PORT.

Would you consider those two URIs to be "the same technology"?

Second question:
Consider the two following models for end-user access to DoH from within an
enterprise network.

   1. Escalation model: The user attempts to contact the DoH server via
      -  If the user is unable to reach the DoH server over NEW_PORT, the
      user is given two options:
         - Don't use that specific DoH server (sub options: pick another
         DoH server, pick a DoT server, pick a Do53 server, don't
connect to the
         - Make an informed (e.g. warnings and explicit user acceptance)
         choice to reach DoH over 443. This may have personal
consequences for the
         user if DoH443 is prohibited and detected.
            - One possible version of this is that the browser facilitates
            a per-user, opt-in configuration, of always doing the
escalation without
            further prompting.
            - Another possible variation is that the browser facilitates a
            per-user, opt-in configuration, of bypassing the NEW_PORT
attempt. This is
            still distinguished from the "Blind Model" in that it is
opt-in, and that
            the user makes a specific informed choice.
         2. Blind model: No assessment of network posture regarding DoH is
   attempted. User contacts DoH on port 443.

What are you saying about model 1?
Are you rejecting it out-of-hand? I
f you are, have you considered the consequences to users?

Commentary on the second question and its implications:
I see several benefits with model 1, to both the users, and the network

   1. It facilitates use of the user's choice of DoH server, when not
   prohibited by the network operator.
   2. NEW_PORT is ONLY used for DoH, so the network operator blocking
   NEW_PORT is an unambiguous signal to the user: you do not have the
   permission of the network operator to access that specific DoH server.
   3. It does not directly block access to the user's choice of DoH server,
   over OLD_PORT (443).
   4. It requires the user's informed consent prior to enabling access to
   the DoH server on OLD_PORT, if NEW_PORT is blocked.
   5. For network operators, blocking or allowing NEW_PORT access scales
   extremely well, since it is applicable only to DoH traffic. In particular,
   it is compatible with the use of white-lists as well as black-lists. In
   contrast, network-level blocking on OLD_PORT fundamentally only supports
   black-lists, unless the operator employs large-scale HTTPS white-lists.

In contrast, here are my observations about model 2 (blind model):

   1. The user is not provided any meaningful ability to provide informed
   2. The user is not able to infer network policy regarding permission to
   access any particular choice of DoH server.
   3. Even if there were a mechanism to express network policy on
   permission to access particular DoH servers, there would not be any
   scalable enforcement mechanism.
      1. The main issue is that white/black lists for web servers and DoH
      servers would be unavoidably commingled. Updates to DoH server
      would have impact on web server access, and the management of those ACLs
      might typically be done by different groups with different
permissions and
      different management systems (possibly incompatible).

The bottom line is, that without a technical mechanism with similar
semantics to the NEW_PORT stuff above, this has direct impact to both
network operators (particularly enterprise network operators), and to users.

Without the NEW_PORT mechanism (or something like it), the network operator
who is required to block some or all DoH servers, must employ un-scalable
methods, which may place significant NEW operational, performance, and cost
burdens on the network operator.
Without the NEW_PORT mechanism (or something like it), the network operator
is unable to distinguish users who would otherwise have been interested in
complying with the network operator's policy (think employees with binding
restrictions which are legal in their jurisdiction).
Without the NEW_PORT mechanism (or something like it), the network operator
is unable to distinguish new DoH servers being access, from random HTTPS
connections occurring. Contrast this with the NEW_PORT semantics: the
network operator would see new failed attempts to reach DoH servers, and be
able to determine whether this is abnormal (malware) or due to a new DoH
operator, where the network operator may wish to facilitate access to the
new DoH operator.

I am interested in your feedback on the above, and whether this affects
your view of the dichotomy.


P.S. Sorry about the confusion caused by your MUA. You might want to report
that to the vendor as a bug.