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

Stephen Farrell <stephen.farrell@cs.tcd.ie> Wed, 27 March 2019 22:46 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 E29941202D4 for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 15:46:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 9EWNo9KoxXsg for <doh@ietfa.amsl.com>; Wed, 27 Mar 2019 15:46:48 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9655712036D for <doh@ietf.org>; Wed, 27 Mar 2019 15:46:47 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E4EF1BEF6; Wed, 27 Mar 2019 22:46:44 +0000 (GMT)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HpmA0_lVELKA; Wed, 27 Mar 2019 22:46:40 +0000 (GMT)
Received: from [31.133.146.21] (dhcp-9215.meeting.ietf.org [31.133.146.21]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 96CCABEE5; Wed, 27 Mar 2019 22:46:40 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1553726800; bh=u71dIrxFTJ1iOik5b27W65yi1sBofMMm2Ay9HRfXkl4=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eT4d8HyLp2nexItDNC3u53nJMf+eWAWAGxiO+12EXu4LUr/V6s0NyYTPhY7PLkoW+ R2xIJY2dJosuQu6a6zMU/q4u+VZojNgLMZWbQQvp30ozDqCavZGttMLo5kcvbLzHHs KDW695ibQy2Q63Yb4hmEwojcMJOXzc4aHTG4ABWI=
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: DoH WG <doh@ietf.org>
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>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Openpgp: id=5BB5A6EA5765D2C5863CAE275AB2FAF17B172BEA; url=
Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw==
Message-ID: <24f0d96b-c6e3-97b8-7ead-b1853b4171f6@cs.tcd.ie>
Date: Wed, 27 Mar 2019 22:46:37 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1
MIME-Version: 1.0
In-Reply-To: <CAH1iCiqEqbVDcaGtC+EzwiHFsFptKbvQMxg34UMO0CojWRb_mA@mail.gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="pVJElKS8NGp1sv315y9N3rhlYXZdCWAQg"
Archived-At: <https://mailarchive.ietf.org/arch/msg/doh/DEUEd13nJsn4cWi4jUPtVS-TOQk>
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 22:46:53 -0000

Hiya,

On 27/03/2019 20:08, Brian Dickson wrote:
> 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 did.

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

There are no such quotes in your mail as rendered by my MUA.

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

I do not accept the above as a useful distinction for this topic.

Those in the category of your first bullet can only be protected
by technology when (essentially) all those in other categories
use the same technology. (That said, I could quibble with your
text, but won't for now:-)

But, and it's a big but, those whose safety is not at risk (today),
also have valid interests to protect, and mechanisms that we have
to offer for such protection need to be widely deployed to be
effective.

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

I won't, sorry. I don't accept your proposed dichotomy as valid.
IOW, our disagreement isn't about the word, but the concept that
such a (likely small) set of people are a usefully distinct set
for this discussion.

Cheers,
S.

PS: I won't respond to your other text below as I think doing so
would be repetitive with the above or wouldn't further the discussion.


> 
> 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.
> 
> 
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>