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

Ted Hardie <> Fri, 15 March 2019 18:36 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6C1E4130EFA; Fri, 15 Mar 2019 11:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HywiLYr_n6yw; Fri, 15 Mar 2019 11:36:51 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::d34]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 064C4130EE4; Fri, 15 Mar 2019 11:36:51 -0700 (PDT)
Received: by with SMTP id x7so9116054ioh.4; Fri, 15 Mar 2019 11:36:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IFBqJsF9fwWObW/VL6XRudjgbJR/ExkrM1E1SUuu0Hw=; b=VuJGPOArnwBNVq0yUT9Ko7O7hCDuN8cyGjaFL9k3NYcc6bITkwSTVMNsjN0Ah7MTFJ PiKFvrOgiKv0lazR/evQXbCtoBIHSq0lHF8pFzoWdDbe0foBXQvWqjzK3iiuKxMIpgwE fjXcdy/ef1OhR49BezSr8QrcH485bA0q1VuygS3kuO3yRO/IDQnfHbdonArauvipn0ah To8ZOt687JdtJj8iQYLqfmSWlms76Sk8f+gHsXdfTMiQK1llwx0ufLOcBVAre5Sw66lt N7nEIJ5bdlJ5uGS1bOL2plH5bU+qDyTqyjNndsxbWT8Xx62pY/WQfe9vaNu1jZb+mGVJ +wuQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=IFBqJsF9fwWObW/VL6XRudjgbJR/ExkrM1E1SUuu0Hw=; b=mVkUuSJd3pHB3wZNyJlDNX+nYwgSHB+MoAuYVQV1FEQL8DAZiUGCrCD1ZhBWF5BkCg uDjID3ENUohQzRAAR/qnEq6NbeS2o5IMemTS66nrbiDpIgZzO8h8HGLatPkOcAdFXKuR TmTCGsfZBdi+dRgFZsJBiZCDYuuAOxEi83cAuTvCBsCc/C+x6fRFOX7gRoe2uAfTJKRN vvCCYLsCFpWoH7NhkofGStwdfJUNy9zbrqc3ounm621SuKot9czXzXRwqfAh2zRQUhiz 2ohiPzgmOL9wkBB2M13pl2PNivUhn0QW4vF6A0YiJT7copGiRxYJEY70Hm9V2lZIXIw7 vplg==
X-Gm-Message-State: APjAAAV+fm6aG51l0iJtcnKmjticKgZWHpLmnHcaOSNu8vefND0M+H7o JHGmQcpyz/K5XSVqlFMMAszO0YjLoXcD0tr8t1tyGhJHzJ8=
X-Google-Smtp-Source: APXvYqwoY4XdxbN/RBVIvlLVTNd3zSlGixsORj6QiNIA3zppypt6owzYfqh/N38CLgetz43JG6ZU8G7/bN+nGt4S0qg=
X-Received: by 2002:a6b:e202:: with SMTP id z2mr3279969ioc.6.1552675009937; Fri, 15 Mar 2019 11:36:49 -0700 (PDT)
MIME-Version: 1.0
References: <> <1914607.BasjITR8KA@linux-9daj> <> <1900056.F7IrilhNgi@linux-9daj>
In-Reply-To: <1900056.F7IrilhNgi@linux-9daj>
From: Ted Hardie <>
Date: Fri, 15 Mar 2019 11:36:22 -0700
Message-ID: <>
To: Paul Vixie <>
Cc: dnsop <>, DoH WG <>
Content-Type: multipart/alternative; boundary="0000000000006b45f00584265253"
Archived-At: <>
Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: DNS Over HTTPS <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Fri, 15 Mar 2019 18:36:57 -0000

Thanks for the thought you've put into this.  I've replied in-line.

On Fri, Mar 15, 2019 at 12:45 AM Paul Vixie <> wrote:

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

All of the work on encrypted DNS presumes that there is one or more parties
who wishes to observe the flow of traffic to DNS resolvers for the purposes
of surveillance.  The conclusion of the IETF after IETF 88 was that there
was a class of that, pervasive public surveillance, that was so damaging to
the trust of the users in the Internet that it amounted to an attack on the
value of the Internet as a whole.  The plenary where that was discussed is
online here: IETF 88 Technical Plenary: Hardening The Internet - YouTube
<> . In
a path with multiple links, in other words, we have a condition where we
believe there is likely to be an attacker on one or more of those links
that would like to see this data and to use it for purposes not approved by
the user or the operator of the service to which the user is directing her
flows (or any of the network operators through which the flow passes).

The response to that has been first to encrypt the flows which carry the
user data.  That's not an effort championed not only by the IETF or the
IAB; see the US Government's HTTPS Only <>standard
for one example of the many other efforts going on to make that the case.
In addition to that primary effort, there have been efforts to reduce the
amount of metadata about the flows.  Some of that has been in updating
transport protocols (e.g. QUIC, TCPINC) to reduce their disclosure of
state.  Some of it has been in reducing the data revealed by the handshake
(e.g. the updates in TLS 1.3 and eSNI).  And some of it has been to reduce
the data disclosed across those links by the use of the DNS.  That's the
point of DNS over TLS and DNS over DTLS; it's also the point of DNS over
HTTPS: to protect the data in those flows from a known, pervasive attacker.

You would like your use of similar surveillance techniques to be
differentiated from their use by that set of attackers.  The IETF cannot do
that on moral grounds, much as we might like you and appreciate your desire
to protect your network and your children. We need technical mechanisms.
If you review the discussion to date, you'll see a number of such
mechanisms proposed.  They fall into two broad classes: trusting the local
network infrastructure and trusting the local configuration.

As was pointed out in many groups, trusting the local infrastructure is
extremely problematic in nomadic cases as the local infrastructure can
often be infected, ill-maintained. or hostile by design.  Given the
extremely high percentage of users who are now on the Internet by mobile
devices which roam and opportunistically use WiFi, ignoring this reality
would not make sense.  So we rely on configuration of end devices and
applications, with the belief that the user has some choice there in both
how the end device is configured and in what applications are supported.
That's a trade-off, and not a simple one to make, both because it is very
difficult for end users to make that assessment and because there's a high
reliance on sensible defaults.  But that choice is an engineering
trade-off, not an act of war against you or any other network operator.

If the user configures your DNS service they get it, and their trust in
your operations to provide appropriate answers is thereby matched to your
desire to see the requests.  For a very large number of enterprise
networks, the result is that devices are permitted on the network only when
under some form of device management, with the proxies, configuration,  and
limitations that implies.  To protect itself, the enterprise insists on a
prior relationship with known terms, instantiated by the configuration of
device management.  There are lighter forms of configuration that do the
same thing to lesser degrees, but they each presume that a trusted edge
network operator has a relationship to the users that can effect

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

This is certainly not the case for all deployments of DoH. Please read
Kenji Baheaux's message on Chrome's plans for an illustrative
counter-example.  In that case,  Chrome will upgrade to DoH on the
configured DNS service.  If the devices on your network use your DNS
service, it will check if DoH is available and upgrade to it if so; it will
not change them to another provider.  DoH is also not set up to allow any
random HTTPS host provide you DNS answers you did not request; this is not
a free invitation to cache-poisoning.

> 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.
> Paul, you are making a major assumption about where the taps for pervasive
surveillance are in the statement above, and it is an assumption I do not
share.  My personal advice would be to have each network operator who cares
about DNS privacy run a recursive resolver using DoT or DoH.  I would say
the same to any multi-site enterprise.

> 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.
> As a reminder, the IAB made the statement, but the IETF chartered the
working group and ran the process.  Like all working groups, it has been
open to all and has passed through a full consensus process.

> > 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.
> The IAB has published a statement about the threat model here (RFC 7624)
and has been working through the Stack Evolution program at least from the
SEMI workshop to develop a view of how to move the network forward with
both encryption and appropriate signals to the on-path devices.  You can
see the discussions around this in radio networks in RFC 8462 and the
upcoming work on protocol wire images and path signals (
and ).  As best as
we can, we want a network that is protected against this attack,
measurable, and manageable.  That's not a simple task, but it is, I
personally believe, the right goal.  The value of the Internet to its users
is too eroded by the lack of confidentiality for it to reach its full
potential without it.

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".
> The past five years have not been the IETF seeking to become a king or
king-maker.  They have been spent responding to an attack while still
building out the facilities of the network.  I am glad to find you a ready
participant now, as there is still work to be done.  But I do not believe
we have said that you may not have these facilities; the new methods simply
mean you must have a relationship with the users and devices on your
network sufficient to effect configuration to use them.  An on-path
adversary does not, but you do.  Yes, that adds a step and some complexity,
but dealing with a new class of attack was never likely to be free.

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

I thought I was asking for your help; if that wasn't clear, sorry.  I would
rather have your help with this than your opposition, and I believe we can
strive for a network that is confidential, measurable, and manageable.  We
aren't there yet, but I hope we share that goal.


Ted Hardie
(wearing no hats).

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