Re: [Doh] Mozilla's plans re: DoH
Brian Dickson <brian.peter.dickson@gmail.com> Thu, 28 March 2019 08:27 UTC
Return-Path: <brian.peter.dickson@gmail.com>
X-Original-To: doh@ietfa.amsl.com
Delivered-To: doh@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 16604120450 for <doh@ietfa.amsl.com>; Thu, 28 Mar 2019 01:27:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eGUk0U8V2fLu for <doh@ietfa.amsl.com>; Thu, 28 Mar 2019 01:27:10 -0700 (PDT)
Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [IPv6:2607:f8b0:4864:20::731]) (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 4F13F12025F for <doh@ietf.org>; Thu, 28 Mar 2019 01:27:09 -0700 (PDT)
Received: by mail-qk1-x731.google.com with SMTP id o129so11593963qke.8 for <doh@ietf.org>; Thu, 28 Mar 2019 01:27:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; 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; d=1e100.net; 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: <CABcZeBOk5bM+3G2Jd3Lu33Z08gc=AeoZ8UFHzN6AYk4f_hjZ8Q@mail.gmail.com> <CABcZeBPUh6x=D+GfKg11+4bRouZdm1LcZvLm1jd4UUEJA832BQ@mail.gmail.com> <alpine.DEB.2.20.1903271629430.13313@grey.csi.cam.ac.uk> <CABcZeBOv0S8gHMYejhGkSncB4kX7KVFiYP3bHPLimdZ==epQQg@mail.gmail.com> <CAH1iCiqPJK=QAVvNufhGJ=uq2d9Znh2puau9GnQukw8vbiu3Ww@mail.gmail.com> <7d8c0bde-3393-7a48-ceeb-cf6db191f260@cs.tcd.ie> <CAH1iCiqEqbVDcaGtC+EzwiHFsFptKbvQMxg34UMO0CojWRb_mA@mail.gmail.com> <24f0d96b-c6e3-97b8-7ead-b1853b4171f6@cs.tcd.ie>
In-Reply-To: <24f0d96b-c6e3-97b8-7ead-b1853b4171f6@cs.tcd.ie>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Thu, 28 Mar 2019 09:26:54 +0100
Message-ID: <CAH1iCipkTKDt+3JkJ+7dzC3Gd1N1ZheoJGbu30R8-YJh7L8b_w@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000edc7aa0585235148"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/qOHhO53YDoBLLtOWJNjaKXs5R6k>
Subject: Re: [Doh] Mozilla's plans re: DoH
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: Thu, 28 Mar 2019 08:27:22 -0000
On Wed, Mar 27, 2019 at 11:46 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> 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.
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH N.Leymann
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Vittorio Bertola
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH Ralf Weber
- [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Matthew Pounsett
- Re: [Doh] Mozilla's plans re: DoH Valentin Gosu
- Re: [Doh] Mozilla's plans re: DoH Kevin Borgolte
- Re: [Doh] Mozilla's plans re: DoH Neil Cook
- Re: [Doh] Mozilla's plans re: DoH Tony Finch
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Stephen Farrell
- Re: [Doh] Mozilla's plans re: DoH Joseph Lorenzo Hall
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Tony Finch
- Re: [Doh] Mozilla's plans re: DoH Vittorio Bertola
- Re: [Doh] Mozilla's plans re: DoH Petr Špaček
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Livingood, Jason
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Vladimír Čunát
- Re: [Doh] Mozilla's plans re: DoH Livingood, Jason
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Adam Roach
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Brian Dickson
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla
- Re: [Doh] Mozilla's plans re: DoH Petr Špaček
- Re: [Doh] Mozilla's plans re: DoH Eric Rescorla