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

Brian Dickson <brian.peter.dickson@gmail.com> Wed, 20 March 2019 05:46 UTC

Return-Path: <brian.peter.dickson@gmail.com>
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 C77FC130F84; Tue, 19 Mar 2019 22:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.701
X-Spam-Level:
X-Spam-Status: No, score=0.701 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=no 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 ej6GY_v-4QML; Tue, 19 Mar 2019 22:46:41 -0700 (PDT)
Received: from mail-qk1-x734.google.com (mail-qk1-x734.google.com [IPv6:2607:f8b0:4864:20::734]) (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 262D212426E; Tue, 19 Mar 2019 22:46:41 -0700 (PDT)
Received: by mail-qk1-x734.google.com with SMTP id k189so8149173qkc.0; Tue, 19 Mar 2019 22:46:41 -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=LYYacSO2tnzoskAztZec85lc3XW+pnHoFVCgxGfYTTo=; b=G3wV3Rwc1FOyY9+52SjkNMlZSu1AZXGkieb52CamLpcoqDyQpTBw0FScLY/oD1akB0 WkkYQKAnuNFnG1SJrVxW6pVTafYe/AxoaZvKhUFGZwUl2nzz3cP5Jbp5S/b5C1onP3lP Hn8GeoCw9a12FQ78P/7MV3+G6PIbo0tHFcOmXBxL3yBAyXz3XOJTJPf6ILzEgVIrPTu6 x8l7J84NgexmzrPGOe1ckPb0PORcAQb5qJwDqwjRDGk2YMunoC6GILZVcgvTtXpmYG9H 4HIjfyyl1oyr61GyxKCh/eVeeJQOWt418W9E02HT51Ilt69OBQ0ikqBK+Z5vxkbpKxBy pySg==
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=LYYacSO2tnzoskAztZec85lc3XW+pnHoFVCgxGfYTTo=; b=EyG+34JLs0/2fRon+/1xBB1mlFPDwqQY/an/hC3mQCVdfjqSwr43zTNpV6f8lHCemR V4RWHRCif6uRuTX0T7hPyB6x6zGRLrelJqoWlK5MG0LkltigLqL4CDqgqPcpfl1JEMjx WsKF/A3BKVWJyOkDv1tjQDKl2rAqMt5OjJ+em+6vjxnwBrQX9vjmsVq2eXWRcb8KfPru XUFVEP0WV1jxOxLdvuvx+aRcJVa9Mp8pdF4zxYzGe3MIq0LPwo6yauHkT3QCLoAzYTjq 2hlQ+RKT+CJExNaj8+ycdjb2Ic3RMP4p0A00HJ4FEW5gR5XipwNkRxfZ+8LnoXCn+QbY RGbA==
X-Gm-Message-State: APjAAAXnOBOiaaXkt/j8hFWaOt4+1L7OZhu8J3IU/VuUrXBjwaSosEET IfQg0INxnPLDKrUFPXrLiYKpQTr3rVRhwXjKmz0=
X-Google-Smtp-Source: APXvYqx4nPJGiFyy94Hj4tgr9pKvpCHIdSncZqTbl7Wy2gAP6VUQWwAR6sjHyqOmFP+CovMN3g4dDV58jBdreXxZqwg=
X-Received: by 2002:a37:6814:: with SMTP id d20mr5182159qkc.102.1553060800175; Tue, 19 Mar 2019 22:46:40 -0700 (PDT)
MIME-Version: 1.0
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>
In-Reply-To: <7f0e4b4f-3b69-cc99-37a6-abff7c0573c0@cs.tcd.ie>
From: Brian Dickson <brian.peter.dickson@gmail.com>
Date: Tue, 19 Mar 2019 22:46:28 -0700
Message-ID: <CAH1iCipyWbsOKwHwTgQrLW4azAUj3Kp0TvD_WiMbT5wcNFm8Ug@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
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>
Content-Type: multipart/alternative; boundary="0000000000004f236605848025b2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/wmVyenEWdymeee1NPV1hwXbIR90>
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 05:46:43 -0000

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.

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.

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?
Are you arguing that they should be able to bypass whatever rules you have
for your children?
Do you want your children to be able to undetectably use a third party DNS
resolver, such as DoH, and access naughty networks or malware?
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.

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?
And should it not be easy to do (where I roughly equate "easy to do" with
"scalable", for argument purposes).


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

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

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