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

Paul Vixie <paul@redbarn.org> Fri, 15 March 2019 07:45 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 BDC2F1311EC; Fri, 15 Mar 2019 00:45:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=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 Vqk57Aig3RGO; Fri, 15 Mar 2019 00:45:02 -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 1DC0C1311EA; Fri, 15 Mar 2019 00:45:02 -0700 (PDT)
Received: from linux-9daj.localnet (vixp1.redbarn.org [24.104.150.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by family.redbarn.org (Postfix) with ESMTPSA id 2D229892C6; Fri, 15 Mar 2019 07:45:01 +0000 (UTC)
From: Paul Vixie <paul@redbarn.org>
To: Ted Hardie <ted.ietf@gmail.com>
Cc: dnsop <dnsop@ietf.org>, DoH WG <doh@ietf.org>
Date: Fri, 15 Mar 2019 07:44:59 +0000
Message-ID: <1900056.F7IrilhNgi@linux-9daj>
Organization: Vixie Freehold
In-Reply-To: <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com>
References: <155218771419.28706.1428072426137578566.idtracker@ietfa.amsl.com> <1914607.BasjITR8KA@linux-9daj> <CA+9kkMAYR19CCCLN00A5Oy_=9Z97FQogCz-vdC=M7Ffn47fTgQ@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"
Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/tWUzDP9KKmY8cB_9Ya4KU0eTrXw>
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: Fri, 15 Mar 2019 07:45:06 -0000

On Tuesday, 12 March 2019 20:52:27 UTC Ted Hardie wrote:
> Paul,
> 
> Since it is apparent our disagreement is at a more fundamental level, I
> will make only two further comments.

ted, your comments were of such a nature that i had to sleep on them more than 
once before i felt i could re-engage. i apologize for the delay. let's 
continue.

> The first is that you recently chided someone for using the word "rant",
> saying that it would "diminish and disrespect" someone's words.  In the
> note below you use terms like "warfare" to characterize the work of the
> authors; that is both inflammatory and disrespectful.  The authors worked
> on a chartered working group item throughout the IETF process.  You
> disagree with the security trade-offs made in the chartering and execution
> of that work, and discussion of that disagreement will hopefully be
> fruitful.  But  if you want their respect of your opinion, according them
> the respect due theirs will go a long way; they did not make these choices
> arbitrarily.

i did not intend the term "warfare" to be taken colloquially. i meant it in 
the literal sense. all war is economic -- the fighting will continue until one 
party cannot afford to continue. not all war is violent. we do not have a word 
like "trade" as in "trade war" to describe what's happening here, and we need 
one, so that i can use that term to describe as accurately as possible what i 
think is happening.

DoH's stated goals include "prevent on-path interference in DNS operations." i 
am an on-path interferer, and "i aim to misbehave"[1]. DoH is, in that sense, 
targeted at me. i think it was wrong to do so, not morally wrong, but wrong on 
its own terms, to falsely equate all on-path interferers. parental controls 
and corporate security are forms of on-path interference in DNS operations 
which have a valid and moral place in our digital society. DoH could have 
distinguished between edge network operators who interfere for reasons our 
users and their apps are either cooperative with or unwelcome entirely. they 
did not. they lumped us all together.

the method of DoH with respect to preventing on-path interference with DNS 
operations is to make it too expensive, obviously, because it (deliberately) 
hides recursive DNS transactions in flows which have been, until now, 
unaffective of DNS operations. i wish the DoH well in their walk with the GFW, 
but i predict that the CCCP has effectively infinite resources and resolve, 
and that it is _not possible_ to exceed their expense budget to the point 
where they say, "ok, that's the end, everybody in china who wants free and 
open DNS access can get it, we just can't deal with this DoH thing."

however, for non-nation-state actors, such as myself, it's going to be really 
quite costly to prevent intruders and bots and other malware from moving their 
DNS operations out of our sight and out of our control. our costs will 
increase. this increase was deliberate.

it would be dishonest not to call that economic warfare by the DoH authors. if 
this comes as a surprise to them, then so much the worse for all of us, i 
think.

> My second comment is to point out that the IETF has been heading this way
> for about five years now.  The IAB formalized its early support of this
> approach in November of 2014 with this text:
> 
> > The IAB urges protocol designers to design for confidential operation by
> > default.  We strongly encourage developers to include encryption in their
> > implementations, and to make them encrypted by default.  We similarly
> > encourage network and service operators to deploy encryption where it is
> > not yet deployed, and we urge firewall policy administrators to permit
> > encrypted traffic.
> > 
> > We believe that each of these changes will help restore the trust users
> > must
> > have in the Internet.  We acknowledge that this will take time and
> > trouble,
> > though we believe recent successes in content delivery networks,
> > messaging,
> > and Internet application deployments demonstrate the feasibility of this
> > migration.  We also acknowledge that many network operations activities
> > today, from traffic management and intrusion detection to spam prevention
> > and policy enforcement, assume access to cleartext payload. For many of
> > these activities there are no solutions yet, but the IAB will work with
> > those affected to foster development of new approaches for these
> > activities
> > which allow us to move to an Internet where traffic is confidential by
> > default.

i remember this text. DoH is not what i expected as "will work with those 
affected". the problem of surveillance is differentiated between home and 
corporate networks on the one hand, and public networks on the other. one 
perfectly valid approach to the goal set out by the IAB above would have been 
to say, all network operators who care about DNS privacy, should run their own 
recursive DNS servers, and, those servers should prefer DoT where available 
when communicating upstream.

that answer was not politically acceptable by other interpreters (that is, not 
me) of the IAB text. rather, the IAB text was taken as license to change the 
way DNS resolution would be done for all users. that was overreach, and was a 
consensus i could not join, and has created more losers than winners, and i 
view it as either naivety about real internet security issues, or as an abuse 
of power, depending on who knew how much at what time.

> By that point, the IETF working groups were already in formation.  Moving
> the DNS toward encryption has been going on since DPRIVE and has been
> accompanied by the rise of transports like QUIC which are encrypted by
> default.  You have been working around that, rather than developing new
> practices.  I invite you instead to consider how you can accomplish what
> you need to in an Internet where all traffic is confidential.

when you talk about "the Internet" which originally meant simply a "network of 
networks", you could mean something technical, in which case my network is one 
of those networks (of which there is a network), and we would likely agree 
that for networks i build and fund, the traffic will be what i accept, not 
what is imposed on me. both the payloads, and the form of those payloads. no 
enterprise or home network operator is going to accept the IETF's mandate as 
to which traffic must be encrypted on our networks, for example.

on the other hand you could mean what christian huitema seems to mean, which 
is an Internet that is viral, and anything that connects to that viral agency 
has to accept all of the payloads and formats decreed by the community. i do 
not expect this view to sway the CCCP, as i wrote above. in any case it does 
not sway me, either as a home network operator or an enterprise network 
operator. simply put, i will not have these views imposed on me. not in the 
form of DoH now, and not in the form of spam back in the 1990's. not ever.

> Enterprises
> are currently doing that via managed software and environments, and that
> approach seems to be well in-line with your practices below.  Using
> resolution systems for this will not accomplish what you need now, nor will
> it do so going forward; it is time for a different approach, rather than
> seeking to return to cleartext.

i am not asking for cleartext per se, though on my own networks, which i build 
and fund, i ought to be able to ask for that and get it, and if you insist 
otherwise, it will be as effective as the IETF's one-time insistence that the 
end to end principle forbade firewalls, and later, the IETF's insistence that 
the end to end principle forbade NAT. the consensus you're seeing appears to 
be in a non-representative bubble.

using resolution systems for surveillance and control of edge networks is the 
world the IETF finds itself in. they can decide to provide other approaches, 
and they would find me a ready participant. they cannot however simply decide 
that my approach is wrong or outdated, and say that those days are over. until 
there is another way to achieve what the internet security industry achieves 
by watching and controlling DNS operations, those operations will continue, 
and they will be non-optional on many edge networks. the IETF consensus is 
not, to borrow a term from christian huitema, "king".

what i'm asking for, though, is not clear text. rather, i'm refusing to allow 
outside answers to naming questions, for the same reasons i would refuse to 
allow outside answers to ARP questions. the internet only exists by 
cooperation -- of which interoperability is only one example. when the wide 
area services, the intermediate networks, the edge networks, the apps, and the 
users all agree on what should happen, then it happens. otherwise, not so. to 
want any other system is to be willing to forcibly impose communications on 
others, which is NOT "the Internet way" and cannot become so, because it would 
rely on cooperation which can be withheld. (as in my case, with DoH.)

> The situation that moved this community to that stance was well-laid out in
> IETF 88.  We must acknowledge that not all devices which are on-path are
> controlled by entities known to the user or network operator and not all of
> them are acting in the interests of those parties.  Protecting against that
> threat requires us to change our ways.  Please help, rather than working
> around the effort.

i don't think you realize what you're asking. the bad guys didn't attend IETF 
88. we have a world wide digital civilization to run here, and we will 
continue doing that, even if it means "working around" disruptions like DoH. 
if someone from the IETF community wants to work on protecting DNS from the 
bad guys without also giving the bad guys greater powers that the good guys 
are nowhere near ready to cope with, my e-mail address is paul@redbarn.org.

> regards,
> 
> Ted Hardie
> (wearing no hats)

i am paul vixie, "concerned internet citizen." thank you for your thoughts. i 
hope that you will also read michael sinatra's response to this same message. 
he does not nec'ily speak for me, but he does seem to be making sense here.

[1] https://www.youtube.com/watch?v=1VR3Av9qfZc