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

Jacques Latour <Jacques.Latour@cira.ca> Wed, 20 March 2019 17:59 UTC

Return-Path: <Jacques.Latour@cira.ca>
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 CD1DD130ECE; Wed, 20 Mar 2019 10:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, 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 4AkPQ_KxT2YM; Wed, 20 Mar 2019 10:59:15 -0700 (PDT)
Received: from mx2.cira.ca (mx2.cira.ca [192.228.22.117]) by ietfa.amsl.com (Postfix) with ESMTP id 36DA6126C87; Wed, 20 Mar 2019 10:59:15 -0700 (PDT)
X-Virus-Scanned: by SpamTitan at cira.ca
Received: from CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) by CRP-EX16-02.CORP.CIRA.CA (10.2.36.121) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.1531.3; Wed, 20 Mar 2019 13:59:13 -0400
Received: from CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7]) by CRP-EX16-02.CORP.CIRA.CA ([fe80::15c6:1482:4083:e9f7%13]) with mapi id 15.01.1531.010; Wed, 20 Mar 2019 13:59:13 -0400
From: Jacques Latour <Jacques.Latour@cira.ca>
To: Jared Mauch <jared@puck.nether.net>, Brian Dickson <brian.peter.dickson@gmail.com>
CC: Ted Hardie <ted.ietf@gmail.com>, DoH WG <doh@ietf.org>, dnsop <dnsop@ietf.org>, paul vixie <paul@redbarn.org>, Michael Sinatra <michael@brokendns.net>, Stephen Farrell <stephen.farrell@cs.tcd.ie>
Thread-Topic: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
Thread-Index: AQHU3st9h0GdiQaaLkiocBQxqOUcOaYUj4IAgAA4OCA=
Date: Wed, 20 Mar 2019 17:59:13 +0000
Message-ID: <6c5968b28fc04566aa71df4c6666e8e2@cira.ca>
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> <EA89EA1A-A1EA-4887-9294-4F68AB5C3211@puck.nether.net>
In-Reply-To: <EA89EA1A-A1EA-4887-9294-4F68AB5C3211@puck.nether.net>
Accept-Language: en-CA, en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [172.16.4.56]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IybF2nRCMKOjRNBxmkJ0vxlKwdQ>
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 17:59:18 -0000

I'm trying to balance in my mind the requirements to protect the DNS vs. what is happening on the wire, in the end, the browser will connect to an IP address which can be (in most case) mapped to a domain name, which we're trying to protect/hide with all sorts of encryption.  Someone that has access to the DNS on the wire can see what is queried, someone with wire access can see who is connecting where.  Where's the privacy protected here? Do we need to balance both?

DoH is going to force enterprises/network operator to beef up their security policies by enforcing higher level of outbound IP address filtering. Having a matching DNS block list in corresponding outbound IP address filters. Going to be messy :-)

Jacques

 

>-----Original Message-----
>From: DNSOP <dnsop-bounces@ietf.org>; On Behalf Of Jared Mauch
>Sent: March 20, 2019 6:10 AM
>To: Brian Dickson <brian.peter.dickson@gmail.com>;
>Cc: Ted Hardie <ted.ietf@gmail.com>;; DoH WG <doh@ietf.org>;; dnsop
><dnsop@ietf.org>;; paul vixie <paul@redbarn.org>;; Michael Sinatra
><michael@brokendns.net>;; Stephen Farrell <stephen.farrell@cs.tcd.ie>;
>Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
>
>
>
>> 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
>_______________________________________________
>DNSOP mailing list
>DNSOP@ietf.org
>https://www.ietf.org/mailman/listinfo/dnsop