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

Jared Mauch <jared@puck.nether.net> Wed, 20 March 2019 10:09 UTC

Return-Path: <jared@puck.nether.net>
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 3978D1310BF; Wed, 20 Mar 2019 03:09:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.201
X-Spam-Level:
X-Spam-Status: No, score=-4.201 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 fM8fvekojy_J; Wed, 20 Mar 2019 03:09:49 -0700 (PDT)
Received: from puck.nether.net (puck.nether.net [IPv6:2001:418:3f4::5]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6950C130F84; Wed, 20 Mar 2019 03:09:49 -0700 (PDT)
Received: from [IPv6:2603:3015:3606:cbe1:cd14:2c86:15f5:ed4e] (unknown [IPv6:2603:3015:3606:cbe1:cd14:2c86:15f5:ed4e]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by puck.nether.net (Postfix) with ESMTPSA id E52A3540F55; Wed, 20 Mar 2019 06:09:36 -0400 (EDT)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\))
From: Jared Mauch <jared@puck.nether.net>
In-Reply-To: <CAH1iCirBm0NKA2-zw--ZKd3gN1ZCmwZ7_ZOSyaTk+2SMmrtxKg@mail.gmail.com>
Date: Wed, 20 Mar 2019 06:09:36 -0400
Cc: Stephen Farrell <stephen.farrell@cs.tcd.ie>, Michael Sinatra <michael@brokendns.net>, Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, paul vixie <paul@redbarn.org>, dnsop <dnsop@ietf.org>
Content-Transfer-Encoding: quoted-printable
Message-Id: <EA89EA1A-A1EA-4887-9294-4F68AB5C3211@puck.nether.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>
To: Brian Dickson <brian.peter.dickson@gmail.com>
X-Mailer: Apple Mail (2.3445.102.3)
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/fHiR8i5Ghuw72m6cdyyVgratfdY>
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 10:09:51 -0000


> On Mar 19, 2019, at 11:17 PM, Brian Dickson <brian.peter.dickson@gmail.com>; wrote:
> 
> 
> 
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell <stephen.farrell@cs.tcd.ie>; wrote:
> 
> Hiya,
> 
> One individualistic data point on this sub-topic, and a real point:
> 
> On 20/03/2019 01:13, Jared Mauch wrote:
> > My impression is there are people who will not be satisfied until all traffic looks
> > identical and you have zero way to protect your home,
> 
> I do not claim that everyone ought do the same, but I absolutely
> do claim that encouraging voluntary policy adherence by dealing
> with the people using the n/w is preferable to many egregiously
> invasive attempts to force technical policy enforcement on
> unwilling serf-like users.
> 
> So, this is the problem:
> - If a network operator has any policy that is enforceable, ONLY the technical policy enforcement model scales.
> - 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.
> 
> This makes the argument you have above, a vacuously defined one. 
> You want to encourage voluntary policy adherence for a non-existent set of otherwise unwilling users.
> 
> I understand your position: you would prefer that {some,all} networks were not employing policies that {you,some people} disagree with.
> I sympathize, but I disagree. What we need are mechanisms that scale.
> My position (personally) is that we find ways to have scalable, technical mechanisms.
> They should allow users (or machine administrators) to be as compliant as they are willing, and no more.
> They should allow networks to enforce their policies, while treading as lightly as possible.
> It should be possible to use technical means to handle this negotiation with little to no user input required.
> The analogy is roughly that of escalation-of-force in law enforcement, starting at a level of "polite requests".
> 
> You can disagree, but I implore you: please don't stand in the way of those wanting to find consensus on scalable, flexible, technical solutions that encompass a wide range of network policies and enforcement needs.
> 
> The main point is, I believe the end result will be mechanisms that allow you to deploy networks that meet your needs, and software that you can configure to bypass such controls, but that neither of those should ever be the default configurations.
> 
> If the results allow you to do what you want/need, and also allow others to do what they want/need, everyone should be happy enough with the result.
> 
> Can we at least agree on this as a desired goal for this work?

Often as an industry we may discuss various solutions that are great for oneself but don’t scale when looking at the big picture.  I’m of the feeling that not everything should be a standard, even things that look like they might be standard-ish.  I could encode many things over TCP over TLS over QUIC over HTTP.  I’ve seen unencoded data stored in DNS TXT records that have sorted/ordered information so you can do interesting things.

Just because one can do these things doesn’t mean one should, or that the entirety of the industry should (or even will).

Goals and motivations are key here, if the goal is to make it such that dissidents whose lives may be threatened (this is an example a co-worker always uses on me in these types of conversations to support their position) by the local regime may face a threatening situation or die as a result of using technology, it’s not the fault of the protocol.  Should we improve for every corner case like this?  As vixie has pointed it, it may be an innocuous device like a chromecast where the ISP provided DNS is horrible.  (I can think of many bad devices in the consumer space that break the DNS spec in really unique ways).  It’s entirely possible that the appliance works best when not using that ISP service, but it is also data leakage to a large global company that for reasonable or unreasonable purposes he doesn’t want to transact with.

When we create technologies that can bypass and traverse the existing security posture of networks (evil foreign telecoms, where’s my pitchfork) or a coffee shop, library, home or large enterprise… expect the work to be held to a higher standard.

It may be that there’s not consensus on this topic.  It may be I’m an outlier and have been subverted by <insert boogeyman of the week here>, but the most likely case is there be dragons here and we should tread carefully to not burn down the entire place.

- Jared