Re: [DNSOP] Draft for dynamic discovery of secure resolvers

Paul Vixie <paul@redbarn.org> Mon, 20 August 2018 17:53 UTC

Return-Path: <paul@redbarn.org>
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 1A31E130E7B for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 10:53:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 tGm2zCFG62x9 for <dnsop@ietfa.amsl.com>; Mon, 20 Aug 2018 10:53:32 -0700 (PDT)
Received: from family.redbarn.org (family.redbarn.org [IPv6:2001:559:8000:cd::5]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB355130E6A for <dnsop@ietf.org>; Mon, 20 Aug 2018 10:53:32 -0700 (PDT)
Received: from [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62] (unknown [IPv6:2001:559:8000:c9:1c6f:2fd8:8c7b:9a62]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id D9199892C6; Mon, 20 Aug 2018 17:53:31 +0000 (UTC)
Message-ID: <5B7B001A.5000907@redbarn.org>
Date: Mon, 20 Aug 2018 10:53:30 -0700
From: Paul Vixie <paul@redbarn.org>
User-Agent: Postbox 5.0.25 (Windows/20180328)
MIME-Version: 1.0
To: Ted Lemon <mellon@fugue.com>
CC: Joe Abley <jabley@hopcount.ca>, dnsop WG <dnsop@ietf.org>
References: <CAC=TB13mUH2SDxFb4c3rOz0-Z6PE_r9i84_xK=dmLxiVr45+tA@mail.gmail.com> <CAPt1N1=-792WkQmbTigPdqOh0dONykYycG0hheOecoQa4ai=Hw@mail.gmail.com> <CAC=TB11tG4o0dkavXGb20=DGBCrmVoRP60bpzsvq5=Q0zFjhDg@mail.gmail.com> <CAPt1N1kj7Y0dPLeDk=PMqQEpAd-Mvds6VLT8XUC1BYOfdyUbJA@mail.gmail.com> <CAC=TB125M81nwiCTNr8Vbee+Z7Fh_3L+6EdZ8evXVzP-2ji4fg@mail.gmail.com> <CAPt1N1n9hDUZQ-Ltvs73T20=fpG-FR_j-t4m0kMapDiv2Us1kw@mail.gmail.com> <5B78BFB9.40103@redbarn.org> <47508D79-0D49-4F31-9BA6-6DC80C38F1DE@cable.comcast.com> <ad1f6dff-ebcc-97a9-6f4b-1ed683827cc7@dougbarton.us> <1313743534.13562.1534765718802@appsuite.open-xchange.com> <9AFE57A7-1D27-4F86-9013-E3C63E63C582@hopcount.ca> <5B7AE322.3020201@redbarn.org> <CAPt1N1m-Xd-7rvgmk8GOsx34=1hsu76nmTgW-8krC3JF7i57KQ@mail.gmail.com> <265867956.15518.1534783313366@appsuite.open-xchange.com> <5B7AF30F.7040409@redbarn.org> <CAPt1N1=ad9MyZmHncTfdDV9pPim9cDC=boAFD9UxmXkpX+vg1Q@mail.gmail.com>
In-Reply-To: <CAPt1N1=ad9MyZmHncTfdDV9pPim9cDC=boAFD9UxmXkpX+vg1Q@mail.gmail.com>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/IvxJvkDpcdPobNX8k9OhhMMdCBU>
Subject: Re: [DNSOP] Draft for dynamic discovery of secure resolvers
X-BeenThere: dnsop@ietf.org
X-Mailman-Version: 2.1.27
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: Mon, 20 Aug 2018 17:53:35 -0000


Ted Lemon wrote:
> On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie <paul@redbarn.org
> <mailto:paul@redbarn.org>> wrote:
>
>     so, their network, but not their rules? when spammers used to tell
>     me that sending spam wasn't illegal and i had to accept it, i
>     blackholed them and said, my network, my rules. who has what rights,
>     and why?
>
> Paul, take a deep breath.   I'm paying for my network service.

if the plural of anecdote was data, i'd counter by saying, my family and 
my employees and my visitors do not pay for my network service. but that 
way lies madness. your network, your rules. if you're paying for it then 
you should make the rules. i pay for mine; i make my own rules.

>> some references i've seen go by in this thread indicate that the DoH
>> team wants its protocol to be unblockable, ...
>
> I think the DoH team is not quite as cohesive as you think it is,
> but yes, that is one implication of the use of DoH. If you find it
> problematic, then you need to get your end users to proxy all their
> HTTPS traffic through your HTTPS proxy. This will be really obvious
> to them, so you won't be able to do it without their agreement.

indeed, DoT was designed to solve this problem -- it can't be 
intercepted or blocked without the user become aware of it. but it's 
designed to be blockable by network operators who don't want it to be 
used. that's better engineering, because it rams nothing down any throat.

> This is by design. This situation has existed since HTTPS has
> existed—it's not something that DoH invented. You've always been able
> to use HTTPS to bypass firewalls; this has good uses and bad. Tough
> luck—see Figure One. :)

see also my own prior work in this area:

https://github.com/BII-Lab/DNSoverHTTP

the difference there was, it's ad hoc, intended to solve point problems 
for individuals, and it would be very easy to block if it caused new or 
worse problems for the coffee shop or hotel room owner.

DOH is designed to be hard to block and to become ubiquitous. that's a 
problem that no amount of gaslighting will reduce the relevance of.

>> if there are use cases beyond violating the law and violating network
>> operator security policy, then they are obviously secondary, but do
>> tell-- what do you think those might be?
>
> Preventing user behavior tracking seems like a pretty valid use case.

it would be, if it was cheap to block. that is, on my network, under my 
rules, user behaviour tracking may be my policy. a user who wants to 
avoid that tracking should ask for non-tracking. if they won't ask, or 
if i say no, then the default should be non-functionality.

the DOH people are trying to ram something down the throats of network 
operators worldwide, and i'm gagging on it. a deep breath won't help.

>> i also block tor endpoints. because, my network, my rules. if it's
>> going to be my network but mozilla's or cloudflare's rules, then this
>> conversation is going to travel very differently, because i'll still
>> be paying for it, but it won't be _my_ network any more. would that
>> sit well with you? it wouldn't with me.
>
> If you think that Mozilla isn't trustworthy, don't use Firefox. It's
> all about trust. It's naive to think that you aren't going to have
> to trust someone; thinking about trust models is no longer optional
> for network operators.

this has nothing to do with trusting mozilla, although in this case, 
they are giving me reasons to treat them as a hostile opponent.

this has nothing to do with what i use. for me it's about employees, 
family members, and visitors. for turkey and china and others, it's 
about national law. the ietf has not been knowingly and deliberately 
hostile to local network policy before now. this is a sea change. it 
will not end here, and it will escalate.

-- 
P Vixie