Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

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

Return-Path: <stephen.farrell@cs.tcd.ie>
X-Original-To: dnsop@ietfa.amsl.com
Delivered-To: dnsop@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49BBD1310C2; Wed, 20 Mar 2019 02:27:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.601
X-Spam-Level:
X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FIN_FREE=2.7, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-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 Avkow1rTnJIR; Wed, 20 Mar 2019 02:27:20 -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 B55321310BF; Wed, 20 Mar 2019 02:27:19 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 57B8CBEE6; Wed, 20 Mar 2019 09:27:17 +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 V27BBWNRJh3S; Wed, 20 Mar 2019 09:27:14 +0000 (GMT)
Received: from [10.244.2.138] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 08F80BE8A; Wed, 20 Mar 2019 09:27:14 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1553074034; bh=Ti67uok1WO2uOgtpb1U5p/IKg/gJvqFSPjXEk1efv+M=; h=To:Cc:References:From:Subject:Date:In-Reply-To:From; b=UTgzMBQS1YNQh23lIFU8J3Y+m4Q1GhOVEFbn8N0ro8F+ZmKl3kKu5kfisP+UWbLcD M5Wi1x1tZ5xxnBGTyb024Yof78r3DpyWa6GX9sjS916dQkHcgOuaPKaJpemLXzdTmT hfGm0AL/+Y9H96uiujA+tuth8HZkshN2zmSOHPFM=
To: Brian Dickson <brian.peter.dickson@gmail.com>
Cc: Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, Jared Mauch <jared@puck.nether.net>, dnsop <dnsop@ietf.org>, paul vixie <paul@redbarn.org>, Michael Sinatra <michael@brokendns.net>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <3457266.o2ixm6i3xM@linux-9daj> <CA+9kkMDkKQtBDrXx9h8331_6zDtcChUTfqFe0W3JByxyB=4xLw@mail.gmail.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com> <a38cf205-b10e-e8e2-62cf-8e0377dfc1ef@brokendns.net> <4599B066-BA82-4EA8-92C1-F1BE1464A790@puck.nether.net> <b8c58757-3945-ea19-b018-8e59292abf30@cs.tcd.ie> <CAH1iCirBm0NKA2-zw--ZKd3gN1ZCmwZ7_ZOSyaTk+2SMmrtxKg@mail.gmail.com> <7f0e4b4f-3b69-cc99-37a6-abff7c0573c0@cs.tcd.ie> <CAH1iCipyWbsOKwHwTgQrLW4azAUj3Kp0TvD_WiMbT5wcNFm8Ug@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: <32c359a7-0b3a-aedf-a761-e8ffc4ccd414@cs.tcd.ie>
Date: Wed, 20 Mar 2019 09:27:12 +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: <CAH1iCipyWbsOKwHwTgQrLW4azAUj3Kp0TvD_WiMbT5wcNFm8Ug@mail.gmail.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="kc6zBpHlYjAstC4BfRMVwv0ydGcAl4HHw"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/lgk4YjJvF4BvVucAhywqP0bDJa0>
Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF DNSOP WG mailing list <dnsop.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dnsop>, <mailto:dnsop-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dnsop/>
List-Post: <mailto:dnsop@ietf.org>
List-Help: <mailto:dnsop-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dnsop>, <mailto:dnsop-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 20 Mar 2019 09:27:23 -0000


On 20/03/2019 05:46, Brian Dickson wrote:
> On Tue, Mar 19, 2019 at 8:36 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>
> wrote:
> 
>>
>>
>> On 20/03/2019 03:17, Brian Dickson wrote:
>>
>>> - If a network operator has any policy that is enforceable, ONLY the
>>> technical policy enforcement model scales.
>>
>> My mail was about my policy for my home network and explicitly said
>> that I do not claim that policy ought be followed by all home networks,
>> never mind other kinds of network. Your argument about scale is not
>> therefore relevant. (At least, not unless you want to give up all
>> argument along the lines of "consider the children.")
>>
> 
> I am saying, that the work product envisioned by participants of the side
> meeting,
> needs to be some framework that scales, regardless of where it gets used.

I'm not at all sure about a "framework" being the output. I do
agree that solutions for networks at all scales are required.

> 
> It does not matter whether any policy does or does not require scalable
> mechanisms.
> What does matter is that there exist networks where the mechanisms need to
> scale.

More than one thing matters. That needs to be kept in mind.

> 
> What is being envisioned and proposed, is a flexible-enough framework, that
> scales.
> 
> If something scales, it scales. If it scales, it won't make it impossible
> to do what you want, tautologically.
> 
> Let's try this using classical logic:
> 
> Suppose there is a rule: "A implies B".
> 
> The negation of that rule is: "Not B implies Not A".
> The negation of that rule is NOT: "Not A implies Not B".
> 
> I believe your argument(s) falls into the "Not A implies Not B" category.
> (I hope I'm mistaken there.)
> 
> However, I am also having a little trouble following your actual meaning.
> More below on my challenge with following what you are saying...
> 
> 
>>
>> My policy, for my network, is as defensible as many others. And that
>> isn't peculiar to home networks.
>>
>>> - In such an environment, there are only, ever, "willing users", because,
>>> in order to use the network, they are required to agree to the policies.
>>
>> Wrong. In my home network, my children and their friends have
>> no real choice to not use the network until they are relatively
>> economically independent. (And in earlier days, they could not
>> have given informed consent in any case, being too young.)
>>
> 
> So, I am trying to understand.
> Does their lack of real choice make them unwilling users?

One could describe it that way. I'm sure many kids might do so;-)
But it's not great terminology.

> Are you arguing that they should be able to bypass whatever rules you have
> for your children?

Most of the "rules" are not enforced by computers, and hence don't
need to be written down precisely. For example, I'd encourage them
to not create accounts on web sites. But I don't try enforce that in
any technical way and accept that sometimes they do end up creating
web accounts. Talking to them about what they're doing and scaring
'em that I could snoop if I was bothered are often sufficient.

> Do you want your children to be able to undetectably use a third party DNS
> resolver, such as DoH,

I don't care about that.

> and access naughty networks 

No, I'd prefer they not. But I have no technical barriers in place
to do such blocking. To the extent that there's a policy at all,
it's defined and (not enforced) purely in the human realm.

> or malware?

Bad question IMO. But in any case, encouraging human behaviour
that doesn't result in malware being executed is IMO more
effective. (E.g. avoiding certain OSes etc.)

> Or do you want to block that particular use case?
> I think their category as "unwilling" is mooted by their being minors and
> not being able to give informed consent.

As I said neither willing nor unwilling are good descriptive terms
for home network users. They are however quite different from
employees in a corporate network (esp in a case like mine with a
technically permissive policy) and that needs to be recognised.

> 
> In any case, if you do want to give them (all of them or some of them)
> access to such third party resolvers, should that not be something
> explicitly under your control?

I don't care about that.

> And should it not be easy to do (where I roughly equate "easy to do" with
> "scalable", for argument purposes).

Ease of use is generally good. I think the challenge for e.g.
browsers, will not reside in networks like mine. I do have
some minor split-horizon issues but nothing that'd break badly
for anyone but me and I know how to handle it.

>> In work environments what you say is also not completely correct,
>> at least in some EU locales, where employees retain rights of
>> various kinds whilst at work using an employer-provided n/w. We
>> don't need to argue the rights and wrongs of that, it just is.
>>
> 
> I think I am also having difficulty with the argument here.

Then feel free to ignore it. My main point is about home networks
but i was responding to how you brought up employees. But in
case it helps...

I'm thinking of the issues that were raised in [1]. The end result
there was that telling employees in advance meant typical corporate
policies were ok, but it's not clear to me if the kind of blocking
we could be discussing here (meaning blocking access to name
resolution) would or wouldn't be considered proportionate, because
it might depend on what services end up being blocked. (IANAL of
course, so I make no claims as to what might happen.)

  [1]
https://www.reuters.com/article/us-privacy-emails-echr/european-court-rules-firms-must-tell-employees-of-email-checks-idUSKCN1BG0YA

> What is the exact scenario (or set of scenarios) you are using in your
> example?

It wasn't my example. It was yours:-)

> 
> Is it an employee located in an EU locale, using a work network?
> And is the employee's network applying policies that violate the employees
> rights?
> If the answer to the second question is "yes", I believe there are many
> recourses that do not involve any technology at all, such as civil suits or
> whatever mechanisms an employee has under the laws of the EU or their local
> jurisdiction.
> I think that any proffered mechanism over and above that is largely
> redundant, and/or generally within the means of a financially independent
> adult to work around, e.g. using a personal device on a mobile network not
> provided by the employer.
> 
> Or, is the employee's network not applying policies that violate the
> employees rights, which I think makes the argument moot, since the
> employee's rights are not actually being infringed.
> 
> So, yes, the employee has rights, and I don't have any issue with either
> the existence of rights, or any opinion on whether that is right or wrong.
> What I don't follow from that is, that any network operator using
> technology to interfere with those rights, is able to do so with impunity,
> and that there is a need to provide mechanisms to bypass that technology.
> Is that really the case, currently, in specific jurisdictions? Can you
> provide some kind of reference to that, that is verifiable, in the EU?
> 
> We all know about the issue with authoritarian regimes, and all that. I
> think we can all agree that in those cases, the use of technological
> methods to bypass restrictions requires individuals to violate the laws in
> those places.

Where there is disagreement is that it's not clear how one could
provide help in that case, but yet allow blocking access to external
recursives in the case of a typical restrictive corporate policy.

> And I am in no way arguing against the technology involved.
> 
> I'm saying that outside of those specific jurisdictions/environments, there
> is no explicit need for making the privacy technology operate in a strictly
> unilateral mode, in such a way as to evade any sort of detection.

It's not clear, to me at least, that what you say there is possible.
But I'm not clear what "unilateral" might mean there.

> I'm saying that it is reasonable to expect that whatever
> legally-permissible policies any network operator has, can be enforced
> cooperatively between client (software/devices), network(s) (operator(s)),
> and server (provider of whatever permitted degree of privacy-enhanced is
> permitted by network operators' policies).
> 
> The extent of what I'm suggesting is, aside from the authoritarian regime
> situation, networks whose policies are not violating local laws (including
> whatever "rights" laws may apply), need to be able to implement those
> policies in a scalable fashion, including detecting anomalous activity
> easily (for e.g. malware detection), and that client software/devices
> should be able to, at their discretion, negotiate the maximal privacy
> setting desired, including reaching a privacy equivalent of "no networks
> available" (don't connect at all).
> 
> 
>> Once more: my policy for my network is defensible but is not
>> one I claim ought be followed by everyone. And the same applies
>> for all of the more intrusive policies being espoused here by
>> those with concerns about DoH.
> 
> 
> We (speaking for everyone else) are NOT espousing policies.

I don't accept that you can speak for everyone else. On what basis
do you say that?

I have seen mails in this discussion asserting that more restrictive
policies do need to be enforced. I hadn't yet seen anyone making such
statements acknowledge that more permissive policies can be as valid.
Hence my bringing up my home network example.

Cheers,
S.

> We are espousing mechanisms for policy enforcement.
> There is a huge difference.
> Our position on the enforcement is policy-agnostic.
> It doesn't matter what the policies themselves are, the mechanisms need to
> scale.
> The policies themselves are, honestly, completely out of scope, other than
> the mechanics.
> If a particular policy is legal in any jurisdiction on this planet, and is
> sufficiently well defined and sufficiently distinct from other policies,
> the policy framework needs to accommodate it.
> There aren't *that* many conceivable policies that apply to DNS in the
> intersection spaces of transport protocol (DoH, DoT, TCP, UDP), third party
> operators (yes/no), encryption (yes/no), and privacy (yes/no/MITM).
> 
> 
>> That doesn't mean those concerns
>> are vacuous or otherwise to be ignored, but does mean that
>> claims as to such-and-such a policy being a necessity are not
>> valid. Only one counter-example is needed to demonstrate that,
>> and I've provided one (that is real, not invented).
>>
> 
> If it is the EU one, please read above: I don't think it actually does what
> you think it does, per se.
> If it is the home network one, it isn't about policy, it is about
> mechanisms, and your not needing your policy to scale, isn't germane.
> If anyone needs the policy framework to scale, that needs to be taken into
> consideration.
> As long as there is anything close to consensus on the existence of a
> non-trivial number of networks who require scalable solutions to this
> problem, that should really be the end of it.
> 
> I don't understand anyone taking a position that anything doesn't need to
> scale, and I think that is what you are saying (from your home network bit.)
> Is that really your position?
> 
> Brian
> 
> 
> _______________________________________________
> Doh mailing list
> Doh@ietf.org
> https://www.ietf.org/mailman/listinfo/doh
>