Re: [Doh] Mozilla's plans re: DoH
Brian Dickson <brian.peter.dickson@gmail.com> Wed, 27 March 2019 20:08 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 C4005120425 for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 13:08:43 -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 09B0WYVWMxt1 for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 13:08:40 -0700 (PDT)
Received: from mail-qt1-x82f.google.com (mail-qt1-x82f.google.com [IPv6:2607:f8b0:4864:20::82f]) (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 8BE941203F6 for <doh@ietf.org>; Wed, 27 Mar 2019 13:08:40 -0700 (PDT)
Received: by mail-qt1-x82f.google.com with SMTP id z17so20391297qts.13 for <doh@ietf.org>; Wed, 27 Mar 2019 13:08:40 -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=xAqolm3BYR9Kou7budnzZN2OyTaJKyz+6nh8pfxWrG4=; b=sCmhS9Ix0Y+YHkPR/pu7f/xFMm0RPOTwH+X1f+K9JtbhDQiWghqdDl7HpK9sz3MVPp q1aR1d1FYZUKDGfWT0HrDnOyUC3yQ3caqi7rMe6hBvhPV5p/b9xERpq9RVk8sp+2/uKl VJHLUMwWKWgvcvvfGQCaLw9zA43UiQKx6aUAqJlLbJLLutxAGgQ1Y0PU9X/1XJ5g9TgP gWobutH6AhfpVb+m96sFHrMrh6Zb+f7Hmh3z84AsTVf1kzJ6EP2GIVcRiohIa4dpc+py 2/rqDGRjkXmgK3jSjH21ZaWY6lB4Ne9ux5IeivRNS4g6dG9/cLabVQLodaszBsmPS6nU qFvQ==
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=xAqolm3BYR9Kou7budnzZN2OyTaJKyz+6nh8pfxWrG4=; b=OpHlC9rIToHQikzribUzGmtdGTi6fJVJmYkKnu2bHhWFV5upeGNf2DV+vHC7orBxlS UYENZMd3gGgUp2/v4zhzewgs5b8AMmBVKyVNX5u4MKmyLSSZQ1d0R0fDXbOFSio3cU5h JCzvM/k5ft9xRfeB3EGzQFTyzWsT98eq+sJTBOACeTsD5IiL0Mq8YXf8qEHfhZT+3x/3 fAlvH78bzNgWMDtwOs1gk7oZJiD9M1xWEEezCz1SmXeHsteJIL2ndo1OF9TPrBA50LW3 JosTfrGvAPEnJX4K/0zUiid4BJQpf4irTVZBXqVBjq7iGtD97l9QiWrFEbDEpJkfJFDg Mzig==
X-Gm-Message-State: APjAAAWwQf3EhyF6gJ0AjtYqccSABtuC85+sm3RsfxfjF/dQZzL5HV34 xb90ZrVr2xFH+5eMIWOOw/YOJbaIu0lrjLe3hOWZ3CwIwSZ4fA==
X-Google-Smtp-Source: APXvYqxcmPuGNp8pxjty6hSnw9EnfgvD3PjAzWoYDfjFbmVXEV+C3tU4zil6hljkOli8A7SuiMNdhIlv+D99WtnACPk=
X-Received: by 2002:a0c:d413:: with SMTP id t19mr32107717qvh.8.1553717319673; Wed, 27 Mar 2019 13:08:39 -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>
In-Reply-To: <7d8c0bde-3393-7a48-ceeb-cf6db191f260@cs.tcd.ie>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Wed, 27 Mar 2019 21:08:27 +0100
Message-ID: <CAH1iCiqEqbVDcaGtC+EzwiHFsFptKbvQMxg34UMO0CojWRb_mA@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: DoH WG <doh@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000ebab190585190035"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/M6NmwnCpRV3J3T5DYil8wxUkY9I>
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: Wed, 27 Mar 2019 20:08:49 -0000
On Wed, Mar 27, 2019 at 7:50 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote: > > Hiya, > > On 27/03/2019 17:34, Brian Dickson wrote: > > dissident mode > If you are going to quote me, please do me the courtesy of doing so correctly. I wrote ' "dissident mode" ', not 'dissident mode' (i.e. it was in quotes, to indicate that I recognize its connotations, but that there is no short phrase that captures the nuances.) I am open to alternate terms, provided they also capture the nuances. (I would also note that the person from the ACLU was specifically referring to dissidents, it was not me alone who used the term.) What I would like to distinguish is: - Persons whose safety requires that their communications and DNS usage be encrypted to trusted servers; persons who do not have alternative ways of accessing trusted DNS, and who by necessity must take actions (using third party encrypted DNS) which may be in violations of laws, contracts, or terms of service (which may be unconscionable but technically legal); persons who are acting in solidarity with the aforementioned folks, or participating in acts of civil disobedience, and - Persons who are taking advantage of legal, permissible, explicitly allowed, and openly available third party DNS over encrypted channels, and refraining from such usage if access is blocked. - From a technological basis, the desire is to facilitate this distinction at scale. One obvious mechanism would be to use distinct TCP port numbers, even if the DoH server is the same (and the same IP address and TLS certificate are used). To facilitate the ongoing discussions, we need some suitable label for the former. If you find the term I originally used objectionable, please provide one for the first group, DISTINCT FROM any corresponding label for the second group. Making assertions that the two groups are actually one group is much worse for the ongoing discussions, and would be materially inaccurate, deliberately conflating the two groups, highly counterproductive, and inflammatory. I would politely ask that you refrain from doing so. (I am not claiming that you have done so, I'm just trying to dissuade such in anticipation of the possibility.) I welcome any label you prefer for the first group. For the second group, any different label from the first group would be fine; I'd suggest "privacy-aware". They use privacy by choice, not by strict necessity (on threat of violence or death), and are freely able to make that choice with no personal consequences. What I am interested in pursing is ways to protect the first group, while enabling the ability for legitimate enterprise policy enforcement (e.g. blocking) to be done scalably. E.g. Make the traffic of the second group identifiable, and to encourage (or require) that how browsers implement the access to the third-party DNS services over encrypted channels, provide a scalable way for networks to block usage for the second group. Here is why having an easy way to distinguish the two groups, at a network level (i.e. TCP port), is important, IMHO: The best protection for the first group, is to have them easily distinguished from the second group. The logic is a bit non-obvious, so let me attempt to explain. The typical volume of traffic by all members of the second group, is likely to be significantly higher than the first group. If enterprise networks have ways of blocking the second group, and if the users in the first group only enable their specific "mode" for limited intervals, the occasional burst of traffic from the first group won't likely result in the enterprise wanting to attempt to block the first group. This has the benefit of not having persistent use of the mechanisms of the first group, and doesn't create the residual risk (e.g. of malware abuse of the first group's DNS traffic). On the other hand, if the exact same mechanism is used by both groups, and there is no practical/simple method of blocking only the second group, the resulting scenario is lose/lose/lose (possibly more "lose" terms). The enterprise would need to employ costly (due to not being scalable), possibly less reliable/available border enforcement, or risk any of the side effects of unconstrained/unblocked DNS carried outside the enterprise via encrypted transport. The impact to the users would be uniform; the second group would be inconvenienced, while the first group would lose their necessary (by definition) DNS privacy. > > As stated at the side-meeting, I think the above phrase is > counterproductive and inaccurate and it'd be a fine thing > if we stopped using that kind of wording. > > It may be counterproductive, but it is accurate. I am distinguishing two use cases, even when the same underlying technology is employed (DNS carried via HTTPS). One is where the user would like to use the technology, and where the access may or may not be permitted, and the user does not exceed the permissions (and thus either uses a different provided DNS service, possibly encrypted, possibly not, or does not user the network at all.) The other use case is where the user must use the technology without regard to whether this activity is permitted. The first group is best categorized as dissidents. From an online dictionary: > a person who opposes official policy, especially that of an authoritarian > state. > "a dissident who had been jailed by a military regime" > synonyms: dissenter, objector, protester, disputant; freethinker, > nonconformist, independent thinker; rebel, revolutionary, recusant, > renegade; subversive, agitator, insurgent, insurrectionist, > insurrectionary, mutineer; informal: refusenik > "a dissident who had been jailed by the regime" If you object to the phrase, please provide a semantically equivalent but inoffensive phrase. Brian P.S. It may not be clear, but I definitely am in favor of providing DoH to everyone who requires it, i.e. members of this specific group. P.P.S. I disagree with "conscripting" unaware users into using the same mechanism using opt-out, always-on resolution via DoH to third party providers. Doing so may place them in jeopardy of one form or another, and is especially objectionable when it is done without explicit and informed consent. The other reason for using technology to block only the second group, is to protect any users who accidentally leave an application or device in the "privacy" mode, when they are on a network which prohibits encrypted access to third party DNS providers. The blockage protects the network; the requirement for explicit user consent to break network policy (and bypass the blockage) is what protects the wayward, innocent user.
- 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