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

[Brian Dickson <[e-mail]>]

On Wed, Mar 27, 2019 at 11:46 PM Stephen Farrell <[e-mail]>
wrote:

> 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):

https://some-resolver.example.com/dns-query
https://some-resolver.example.com:<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
   NEW_PORT.
      -  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
         network)
         - 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
operators:

   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
   consent.
   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
permissions
      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.

Sincerely,
Brian

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