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

From: Warren Kumari <[email-masked]>
Date: Sun, 10 Mar 2019 15:48:52 +0900

[ + DNSOP]

On Sun, Mar 10, 2019 at 12:31 PM Jim Reid <[email-masked]> wrote:

> FYI colleagues. The draft below has just been submitted. I've been given
> 10 minutes of WG agenda time at IETF104.
>

I haven't given this a full review yet, but I'd like to note that almost
all of this is about concerns around applications (including browsers)
deciding to use their own name resolution and bypass the system resolver,
and that very little of this document is actually about DoH itself.

I think it would be very valuable to not conflate DNS-over-HTTPS (the
protocol) with the "applications might choose to use their own resolvers"
concerns.
As an example:
" For most users, DNS resolution is
      currently part of the service provided by their ISP.  With DoH,
      users can be expected to rely on DoH service providers and are
      likely to have no business or contractual relationship with those
      providers."

This about the latter, and I *really* think that this is not helpful to use
the term DoH to refer to it -- applications have always been able to write
code to bypass the system resolver if they had chosen to - for example
apps, including browsers, could have equally done this with "plain DNS",
DNS-over-TLS, DNS over foo, etc. As an example it appears that the NetFlix
apps have been bypassing the system resolvers sinde before the times of
DoH. Yes, the Mozilla / CloudFlare experiment used the DoH protocol, but it
could queally have used DoT, DNS over IPSec, $whatever.

I encourage discussion of the concerns and what the implications of
applications doing their own DNS are, but they are different to the DoH
protocol - please do not conflate / confuse the two.
Someone (it may have been Vittorio Bertola) coined the term DNS-over-Cloud
(DoC) to refer to the deployment concerns - while I don't think it is a
great term, it is much better than  using the the term DoH to refer to all
of:
1: the protocol,
2: the deployment concerns,
3: "resolverless DNS",
4: the loss of visibility from encrypting the DNS

Also, I think that this topic would be better discussed in the DNSOP WG -
the DoH charter (https://datatracker.ietf.org/wg/doh/about/) talks about:
"The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS clients (e.g.,
operating
system stub resolvers) and recursive resolvers."

While it does say:
"The working group will analyze the security and privacy issues that
could arise from accessing DNS over HTTPS. In particular, the working
group will consider the interaction of DNS and HTTP caching."
it goes on to say:
"In particular, DNSOP will be consulted for guidance on the
operational impacts that result from traditional host behaviors (i.e.,
stub-resolver to recursive-resolver interaction) being replaced with the
specified mechanism."

So can the document please be updated to discuss either the DoH protocol
*or* the larger issues - and if the latter, this document / discussion
should happen in DNSOP.

W

> > A new version of I-D, draft-reid-doh-operator-00.txt
> > has been successfully submitted by Jim Reid and posted to the
> > IETF repository.
> >
> > Name:         draft-reid-doh-operator
> > Revision:     00
> > Title:                DNS over HTTPS (DoH) Considerations for Operator
> Networks
> > Document date:        2019-03-10
> > Group:                Individual Submission
> > Pages:                17
> > URL:
> https://www.ietf.org/internet-drafts/draft-reid-doh-operator-00.txt
> > Status:
> https://datatracker.ietf.org/doc/draft-reid-doh-operator/
> > Htmlized:       https://tools.ietf.org/html/draft-reid-doh-operator-00
> > Htmlized:
> https://datatracker.ietf.org/doc/html/draft-reid-doh-operator
> >
> >
> > Abstract:
> >   The introduction of DNS over HTTPS (DoH), defined in RFC8484,
> >   presents a number of challenges to network operators.  These are
> >   described in this document.  The objective is to document the problem
> >   space and make suggestions that could help inform network operators
> >   on how to take account of DoH deployment.  This document also
> >   identifies topics that may require further analysis.
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf

---

From: Paul Vixie <[email-masked]>
Date: Sat, 9 Mar 2019 23:01:33 -0800

Warren Kumari wrote on 2019-03-09 22:48:
> ...
> protocol) with the "applications might choose to use their own 
> resolvers" concerns.

i disagree. as an example:

>    Two primary use cases were considered during this protocol's
>    development.  These use cases are preventing on-path devices from
>    interfering with DNS operations, ...

(from the Introduction of RFC 8484.)

no other off-network RDNS is reachable by malware which somehow gets 
into my network, or BYOD devices that have a coffee-shop configuration, 
or any other rogue purpose which is at odds with me as the operator of 
"on-path devices". i intend to interfere. DoH turns traditional rules on 
their head, and does so _deliberately_.

if the authors of DoH don't want to be lumped in with the "apps 
(malware) that might choose to use their own resolvers" then they ought 
to have designed it to work in concern with local network policy. in 
other words, make it blockable. by explicitly and aggressively taking 
the position they took, they own the followup, including the Reid draft.

i have been away as long as possible, which means i was surprised that 
the IESG was willing to allow a document to standardize hostility 
between me as a parent and my children who are subject to my parental 
controls technology, and between me as a network operator and malware 
authors who can't succeed without bypassing my DNS servers.

but, the cat is out of the bag now, and it's going to be pretty messy. 
please do not blame that mess on jim reid or on his draft.

-- 
P Vixie

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 10 Mar 2019 11:58:15 +0100

On Sun, Mar 10, 2019 at 03:48:52PM +0900,
 Warren Kumari <[email-masked]> wrote 
 a message of 281 lines which said:

> I think it would be very valuable to not conflate DNS-over-HTTPS
> (the protocol) with the "applications might choose to use their own
> resolvers" concerns.

I fully agree.

Applications using their own resolver is Bad, IMHO, but 1) it is
unclear what the IETF can do since it is outside of the protocol field
(may be documenting our concerns?) 2) it has little to do with DoH.

> (DoC)

Bert Hubert <https://blog.powerdns.com/2019/02/07/the-big-dns-privacy-debate-at-fosdem/>

> 3: "resolverless DNS",

I personnaly don't agree with "resolverless DNS". There *is* a
resolver, just not the "usual" one.

> Also, I think that this topic would be better discussed in the DNSOP

Again, I fully agree, since it is not DoH-specific.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sun, 10 Mar 2019 12:01:20 +0100

On Sat, Mar 09, 2019 at 11:01:33PM -0800,
 Paul Vixie <[email-masked]> wrote 
 a message of 32 lines which said:

> i have been away as long as possible, which means i was surprised
> that the IESG was willing to allow a document to standardize

I'm not surprised, since, in the last years, there have been a strong
increase in network neutrality violations, censorship through DNS,
privacy invasions, etc. I'm glad the IETF (not just the IESG) decided
to act and to develop techniques that can help to restore some sort of
access.

---

From: Ask Bjørn Hansen <[email-masked]>
Date: Sun, 10 Mar 2019 12:15:53 -0700

> On Mar 9, 2019, at 10:48 PM, Warren Kumari <[email-masked]> wrote:
> 
> Also, I think that this topic would be better discussed in the DNSOP WG -  the DoH charter (https://datatracker.ietf.org/wg/doh/about/ <https://datatracker.ietf.org/wg/doh/about/>) talks about:
> provides confidentiality and connectivity between DNS clients (e.g., operating

I agree with this (and everything else you said).

The new topics that are coming up all seem like they’d fit better in DNSOP or DPRIVE.

I see promise in DoH for the ways it might (eventually) change our technology options to better make use of the (much larger than DNS) investments in infrastructure for HTTP (and HTTP/2,3, …).

The “DoC” / policy / operational work is important, but I don’t understand what’s DoH specific about it.

Ask

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 11 Mar 2019 03:03:02 +0100 (CET)

> Il 10 marzo 2019 alle 20.15 Ask Bjørn Hansen <[email-masked]> ha scritto:
> 
> 
> 
> 
>         > >         On Mar 9, 2019, at 10:48 PM, Warren Kumari < [email-masked] mailto:[email-masked] > wrote:
> > 
> >         Also, I think that this topic would be better discussed in the DNSOP WG -  the DoH charter ( https://datatracker.ietf.org/wg/doh/about/) talks about:
For the sake of completeness, I will mention that I have also just posted a draft that tries to address the issues deriving from the adoption of encrypted DNS protocols, under the form of a best practice document for client applications:

https://mailarchive.ietf.org/arch/msg/dns-privacy/3ryu5BxcjRJO1-zeRXJaKIcIDUY

I decided that dprive was the right place for it, and I will briefly present it there, but I agree that the first discussion (even in a side meeting in Prague, if there is interest) would be where to deal with the topic within the IETF, and to which extent; it would make sense to have a single coordinated discussion rather than multiple parallel ones.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] mailto:[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Ted Hardie <[email-masked]>
Date: Mon, 11 Mar 2019 10:02:58 -0700

On Sat, Mar 9, 2019 at 11:03 PM Paul Vixie <[email-masked]> wrote:

> into my network,

I interpret this to mean that you have blocked DNS over TLS's well-known
port (853), so that Quad 9 and other services offering it are not
accessible.  Is that correct, or do you mean something more extensive?

As several other folks have pointed out, roll-your-own resolution is in
some pretty widely used applications, but I'm not aware of any
comprehensive list or any way to block that short of removing the
applications once found.  Is there a technique here I'm not aware of?

Ted

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Mar 2019 11:06:56 -0700

Ted Hardie wrote on 2019-03-11 10:02:
...
> accessible.  Is that correct, or do you mean something more extensive?

that's it. because before DoH, it was possible to outlaw off-net 53 and 
853 except when coming from my local RDNS servers. because unlike DoH, 
those protocols are not designed to prevent on-path interference.

> applications once found.  Is there a technique here I'm not aware of?

famously, my chromecast ultra would not let itself out of setup mode 
until it was allowed to reach 8.8.8.8 on UDP/53.

https://www.businessinsider.com/paul-vixie-blasts-google-chromecast-2019-2

my solution was to operate a server on 8.8.8.8 (and 8.8.4.4, and 
9.9.9.9, and 1.1.1.1) locally.

DoH will moot that approach. (by design.) i'm studying my alternatives, 
since i also use 'dnstap' to detect behavioural abnormalities, and DNS 
RPZ for parental (and botnet, and IoT) controls. it won't be pretty and 
it won't be cheap. (by design.)

-- 
P Vixie

---

From: Ted Hardie <[email-masked]>
Date: Mon, 11 Mar 2019 11:30:51 -0700

On Mon, Mar 11, 2019 at 11:06 AM Paul Vixie <[email-masked]> wrote:

>
> DoH will moot that approach.
>

Any system that actually checks the credentials presented by the responding
server will also moot that approach.  Given how easy it is to pin
credential characteristics in applications distributed as binaries, this
seems to mean that your method will either continue to permit applications
other than browsers to use their own resolution systems or it will hard
fail all such applications it can identify.  No pass through will work, as
far as I can tell, in that scenario.

Perhaps, though, I am missing something about your intent.

Ted Hardie

--

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Mar 2019 18:27:11 +0000

On Monday, 11 March 2019 18:30:51 UTC Ted Hardie wrote:
> server will also moot that approach.

yes! but it will fail "closed". thus, no unauthorized exfiltration risk will 
exist.

> Given how easy it is to pin

that's precisely the goal, because very few network operators can preordain 
the users and apps that will connect through their networks. to the extent 
that monitoring ('dnstap') and controlling (DNS RPZ) dns lookups by connected 
users and apps is considered a vital local security policy, attempts at such 
"pass through" must be made to fail.

> Perhaps, though, I am missing something about your intent.

i think you've restated some key points of my position with perfect accuracy.

DoH wants to empower users and apps to make decisions about their RDNS which 
cannot be interfered with by on-path actors such as their own network 
operators. by doing this, DoH makes a false equivalence between a dissident 
(who may be considered a criminal in some places) and a criminal (who is 
always considered a criminal in most places) and private users in a hotel room 
or coffee shop or on their home broadband connection, and malware which gets 
inside a network and wants to avoid detection/mitigation while performing 
lookups or exfiltration.

those are four very different things. demanding identical treatment for all of 
them is, in the best possible interpretation, naive.

vixie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 12 Mar 2019 12:15:16 -0700

Hi Paul,

Comments in-line.

On Tue, Mar 12, 2019 at 11:27 AM Paul Vixie <[email-masked]> wrote:

> the users and apps that will connect through their networks.

I do not believe this goal is met by what you describe, since an
application can use a proprietary resolution service in its flows.  Imagine
for a moment an application on a smart TV that wants to provide content
from the closest server which contains that content.  It can use a redirect
from the original server when a new, closer server comes online (or when a
different server has that content), and it can provide the mapping between
that server and one or more addresses for that server with the redirect, in
whatever format its individual cache can store.  All of this can take place
within its confidential channel, using whatever proprietary format they
find convenient.  In that case, the local network will see new flows to the
new servers without having observed the resolution event.  Blocking
destinations for which you have seen no resolution events will work for a
subset of these cases, but it won't work when the resolution points to a
common CDN destination.  That approach will, of course, also have a wide
variety of failure modes when the resolution event data is incomplete for
timing or other reasons; it will also block all of the flows which MUD
would handle.

to the extent
> "pass through" must be made to fail.

Those are security mechanisms, rather than policy, and it may be worth
teasing apart what the actual desired security policy is.  You may find
that it is more easily implemented at the routing layer than the resolution
system in the light of proprietary resolution systems and DoH.

regards,

Ted Hardie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Mar 2019 20:22:00 +0000

On Tuesday, 12 March 2019 19:15:16 UTC Ted Hardie wrote:
> ...
> > that's precisely the goal, because very few network operators can
> > preordain the users and apps that will connect through their networks.
> 
> application can use a proprietary resolution service in its flows.

rogue flows have their own accounting. my problem isn't with one-off's, 
because traditional security is anomaly-based. DoH, by folding control plane 
data into previously non-anomalous flows, presents a new problem. if CF and G 
and IBM and Cisco decide to offer DoH on the same IP address that they offer 
API's and services i actually do need or want to permit, i'm going to have to 
increase my investment.

this equation, where something is created which is a danger to me, which 
blends in with the crowd of things that are not dangerous to me, is the method 
by which DoH achieves its stated aim, "prevent on-path interference in DNS 
operations." all war is economics. they are increasing my costs, deliberately.

i am on-path and i intend to interfere. at whatever cost that may be. i also 
reserve the right to re-externalize some or all of those new imposed costs.

> Imagine for a moment an application on a smart TV that wants to provide
> content from the closest server which contains that content.  ... Blocking

generally speaking, security policies break down into two categories. allow 
all except some, or deny all except some. which one an operator chooses will 
depend on their goals, budgets, and in particular, the cost of anomaly 
detection. it's the change in cost of anomaly detection, deliberately intended 
by the authors of RFC 8484, which is at the root of some very expensive policy 
choices that the rest of us must now make.

your smart-tv example is not involved in that causalality path. noting also, i 
have a TV which offers the kind of feature you describe, but only if i accept 
its software license. (something to do with GDPR, i suspect.) so i did not 
accept that license, and as a result, i have a disconnected device whose 
flaws, both now known and not yet known, will pose no threats here. my TV, my 
rules.

> > to the extent that monitoring ('dnstap') and controlling (DNS RPZ) dns
> > lookups by connected users and apps is considered a vital local security
> > policy, attempts at such "pass through" must be made to fail.

> system in the light of proprietary resolution systems and DoH.

to be clear, the policy is, "allow all, except some". i implement as much of 
this policy as possible at the routing layer, and i do my research on 
proprietary resolution systems to decide whether i can tolerate the risks of 
devices which use such things. (so, no nest thermostats here, the TV's are not 
smart, and the apple home pods are in their not-logged-in state.)

it is the standards nature of DoH that amplifies its imposed costs. i could 
simply outlaw by IP or port# a proprietary or otherwise bespoke protocol. 
(working out with my kids what online games require what permissions, has been 
burdensome on both me and them.) DoH, by _intending to bypass_ network 
operator policy DNS, and my seamlessly hiding in the crowd of TCP/443 
transactions now made indiscernible  by TLS 1.3 and ESNI, is an act of 
economic warfare against all RDNS control plane owners. (deliberately.)

vixie

---

From: Ted Hardie <[email-masked]>
Date: Tue, 12 Mar 2019 13:52:27 -0700

Paul,

Since it is apparent our disagreement is at a more fundamental level, I
will make only two further comments.

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.

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

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.

regards,

Ted Hardie
(wearing no hats)

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 12 Mar 2019 14:52:50 -0700

I realize you're responding to Paul, but your message below did pique
(in a good way) my thinking and the distinction in my mind, as an
operator, between DoH and DoT (and other forms of encrypted
communication).  I am top-posting intentionally because I am responding
to your entire message.

I support TLS 1.3 as written.  I support DoT.  I support DNSSEC,
HTTPS-everywhere, HSTS, etc.  I am a big fan of confidentiality and
privacy.  DoT gives us that.  DoH does too, but it also gives us
protocol obfuscation, and that makes me uneasy as an operator.  I
understand that in certain environments, this is seen as a good thing,
but I can also imagine a number of environments where this approach will
create considerable collateral damage and greatly hamper efforts at risk
mitigation.  Put differently, if we try to work around what our CISO is
legitimately trying to do, they will come out with bigger and more
expensive ban-hammers[1], and that will potentially lead to an arms race
of more workarounds and even bigger ban-hammers.

I think DoT makes a good compromise between confidentiality and protocol
transparency.  DoH does not because it intentionally works against
protocol transparency.  Again, that's what makes me uneasy and why I
support the efforts behind the various internet-drafts that we're
discussing here.

michael

[1] As an example, I am personally and practically opposed to inline TLS
decryption in most enterprises.  DoH gives further ammo for security
folks to insist on inline TLS decryption, IMO.  DoT, not as much, since
the protocol can be easily identified on the wire and any necessary
actions taken.  Manipulating DoT transactions is a far cry from
manipulating/decrypting all TLS...

On 3/12/19 1:52 PM, Ted Hardie wrote:
> 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.
> 
> 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:
> 
> 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.
> 
> 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.
> 
> 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. 
> 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.
> 
> 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.
> 
> regards,
> 
> Ted Hardie
> (wearing no hats)
> 
> 
> On Tue, Mar 12, 2019 at 1:22 PM Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop
>

---

From: Raymond Burkholder <[email-masked]>
Date: Tue, 12 Mar 2019 21:05:10 -0600

On 2019-03-12 1:15 p.m., Ted Hardie wrote:
>     preordain

but there are more than just network operators.  There are security 
people at all levels of organizations who are extremely interested and 
who are empowered to manage/monitor what is happening inside a network. 
DoH removes much of this power.  I'm not sure if that is a 'good thing'.

> content from the closest server which contains that content.  It can use 
> a redirect from the original server when a new, closer server comes 
> online (or when a different server has that content), and it can provide 
> the mapping between that server and one or more addresses for that 
> server with the redirect, in whatever format its individual cache can 
> store.  All of this can take place within its confidential channel, 
> using whatever proprietary format they find convenient.  In that case, 
> the local network will see new flows to the new servers without having 
> observed the resolution event.  Blocking destinations for which you have 
> seen no resolution events will work for a subset of these cases, but it 
> won't work when the resolution points to a common CDN destination.  That 
> approach will, of course, also have a wide variety of failure modes when 
> the resolution event data is incomplete for timing or other reasons; it 
> will also block all of the flows which MUD would handle.

I think that is to be expected:  when a network operator (enterprise, 
home, organization) is dynamically adjusting ip based rule-sets based 
upon what meta-data can be derived from flow inspection.  If a 
proprietary resolution service is used, then it is expected that 'by 
default blocks' will be performed if the traffic protection engine is 
not appraised of change.

If DoH is implemented, then traffic, whether it be lookup, or otherwise, 
in a 'default drop' scenario is just going to have to be, well, 'default 
dropped'.  Brute force I guess is the protection mechanism.

So, I think, then, this begs the question, how can the needs/desires of 
those in charge of security be balanced with the needs/desires of those 
who desiring to bypass inspection?

I guess the maxim 'my network, my rules' holds.  But what DoH will cause 
is an even increasing tightening of network rules.  With current passive 
DNS pass-through, DNSEC and such can remain unmolested, but at least 
follow-on flows can be identified for forensic or security or policy 
purposes.  With DoH, this correlation can not be performed, and thus, by 
default, a user's ability will be more restricted in order to prevent 
unknown unknowns from happening.

The only way around this, for a security operator's perspective, will be 
certificate insertion so that proxying can be performed. And we are back 
to what we currently have anyway.

Would a compromise be that, if someone requires personal security, the 
standard fall back would be to use a VPN?

> that it is more easily implemented at the routing layer than the 
> resolution system in the light of proprietary resolution systems and DoH.

You've mentioned that 'security' is separate from 'policy' and then 
mention 'security policy'.  And I implicitly agree with the latter, 
security and policy go hand in hand, and are difficult to separate.

Handling at the routing layer is not possible.  Handling at the 
interrogation/interception/transparent-evaluation intelligence layers is 
where it begins.  This information then feeds the interior/perimeter 
protection layers.  The policies implement the security.

If the interrogation/interception/transparent-evaluation layers are 
unable to identify key interactions, then security is unable to be 
performed.

Raymond

---

From: Raymond Burkholder <[email-masked]>
Date: Tue, 12 Mar 2019 21:20:22 -0600

> move to an Internet where traffic is confidential by default.

So... would someone be able to identify some of the 'new approaches' 
which help security practitioners ply their trade?

If these approaches were identified, then perhaps there would be less 
resistance to maintaining access to the cleartext flows we use to 
maintain security state.

> what you need to in an Internet where all traffic is confidential.  

Can some of these new practices be part of the protocol development process?

> practices below.  Using resolution systems for this will not accomplish 

Where can I read up on some of these practices?

---

From: Paul Vixie <[email-masked]>
Date: Fri, 15 Mar 2019 07:44:59 +0000

> 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 respect due theirs will go a long way; they did not make these choices

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.

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

> 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

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

> threat requires us to change our ways.  Please help, rather than working

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 [email-masked].

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

---

From: "Winfield, Alister" <[email-masked]>
Date: Fri, 15 Mar 2019 08:49:48 +0000

On 15/03/2019, 07:45, "Doh on behalf of Paul Vixie" <[email-masked] on behalf of [email-masked]> wrote:

    I might also note that the outcome of blocking such 'interference' will likely increase the chance of successful data exfiltration by the 'unwelcome'. Thus in fact this "privacy" protocol may one day be shown to reduce overall privacy and security for the majority of users due to yet more data leaks.

Alister Winfield

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD

---

From: Ted Hardie <[email-masked]>
Date: Fri, 15 Mar 2019 11:36:22 -0700

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

> 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
<https://www.youtube.com/watch?v=oV71hhEpQ20&feature=youtu.be&t=8615> . 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 <https://https.cio.gov/>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
configuration.

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

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

> 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 (
https://datatracker.ietf.org/doc/draft-iab-wire-image/
and https://datatracker.ietf.org/doc/draft-iab-path-signals/ ).  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
> 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.

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

regards,

Ted Hardie
(wearing no hats).

> the bad guys didn't attend IETF

---

From: "John Todd" <[email-masked]>
Date: Fri, 15 Mar 2019 14:34:37 -0700

On 12 Mar 2019, at 20:05, Raymond Burkholder wrote:

> who are empowered to manage/monitor what is happening inside a 
> network. DoH removes much of this power.  I'm not sure if that is a 
> 'good thing'.
>
>> Imagine for a moment an application on a smart TV that wants to 
>> provide content from the closest server which contains that 
>> content.  It can use a redirect from the original server when a new, 
>> closer server comes online (or when a different server has that 
>> content), and it can provide the mapping between that server and one 
>> or more addresses for that server with the redirect, in whatever 
>> format its individual cache can store.  All of this can take place 
>> within its confidential channel, using whatever proprietary format 
>> they find convenient.  In that case, the local network will see new 
>> flows to the new servers without having observed the resolution 
>> event.  Blocking destinations for which you have seen no resolution 
>> events will work for a subset of these cases, but it won't work when 
>> the resolution points to a common CDN destination.  That approach 
>> will, of course, also have a wide variety of failure modes when the 
>> resolution event data is incomplete for timing or other reasons; it 
> If DoH is implemented, then traffic, whether it be lookup, or 
> otherwise, in a 'default drop' scenario is just going to have to be, 
> well, 'default dropped'.  Brute force I guess is the protection 
> mechanism.
>
> So, I think, then, this begs the question, how can the needs/desires 
> of those in charge of security be balanced with the needs/desires of 
> those who desiring to bypass inspection?
>
> I guess the maxim 'my network, my rules' holds.  But what DoH will 
> cause is an even increasing tightening of network rules.  With current 
> passive DNS pass-through, DNSEC and such can remain unmolested, but at 
> least follow-on flows can be identified for forensic or security or 
> policy purposes.  With DoH, this correlation can not be performed, and 
> thus, by default, a user's ability will be more restricted in order to 
> prevent unknown unknowns from happening.
>
> The only way around this, for a security operator's perspective, will 
> be certificate insertion so that proxying can be performed. And we are 
> back to what we currently have anyway.
>
>>     that monitoring ('dnstap') and controlling (DNS RPZ) dns lookups 
>> by
>>     connected
>>     users and apps is considered a vital local security policy, 
>> attempts
>>     at such
>> Those are security mechanisms, rather than policy, and it may be 
>> worth teasing apart what the actual desired security policy is.  You 
>> may find that it is more easily implemented at the routing layer than 
>> the resolution system in the light of proprietary resolution systems 
>> and DoH.
>
> interrogation/interception/transparent-evaluation intelligence layers 
> is where it begins.  This information then feeds the 
> interior/perimeter protection layers.  The policies implement the 
> security.
>

[removing [email-masked] from cc: list, as this message is on operational 
implementation only]

Agreed with what Raymond has said above, and most of what Paul Vixie has 
said previously on this topic. We see no significant improvement that 
DoH brings to security or privacy that DoT does not already offer, and 
also believe DOH’s stated goal of obscurity via port and origin source 
IP conjoining is dangerous and ultimately misguided in respect to the 
goals of increasing privacy and permitting content access. Keep control 
and content channels separate, even if it allows blocking to be easily 
effective. If there is the thought that clever obfuscation will prevent 
blocking, then that is vastly underestimating the legal, administrative, 
and commercial force which will be applied to prevent the DoH model one 
widely adopted, and then the subsequent privacy wreckage that force will 
cause.

We expect to see the “block everything and force national/enterprise 
certs” model expanding in the near future, which we believe to be 
++bad. DoH throws gasoline on that fire if content and DNS are 
indistinguishable and commonly bundled. Maybe always-proxied connections 
are an inevitable condition for some large portion of Internet users, 
but we would prefer not to see the angle of the growth slope increase so 
quickly as it might if DoH is implemented in ways that aggressively and 
intentionally oppose local network policy enforcement.

Quad9 supports DoH currently, but recommends DoT. We are not opposed to 
DoH as a protocol, but we fear the political results of deployment 
models by others which take Internet content as hostage in front of DoH 
services. The optimistic hope by DNS operators that websites can be used 
as a “shield” against blocking will end badly for the people who 
need security the most, since those users are typically on networks or 
within nation-states which have the highest incentives to react strongly 
and in a privacy-negative way to perceived or real policy circumvention 
at scale. Mainland China’s example of network filtering is a template 
to control-oriented operators as one such response result.

We will not serve non-Quad9 HTTPS content on the same IP addresses as 
our public resolvers. We will keep the number of DNS-serving endpoints 
we operate to a relatively small list of anycast netblocks that can be 
identified as being “DNS-only” in nature. We hope that organizations 
that offer content and open DNS recursive resolution will not try to 
combine DNS and HTTPS in a way that is impossible to “cheaply” block 
by local network operators. Otherwise we see a condition where those 
operators in the hopes of regaining control will choose to block/proxy 
all traffic to all destinations, and not just block DNS. If that type of 
deny-all (or “intercept-all”) filter is implemented as it has been 
in existing examples then this appears to us to be a worse outcome that 
we would want to try to avoid.

JT

--
John Todd - [email-masked] - +1-415-831-3123
Executive Director - Quad9 Recursive Resolver

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 16 Mar 2019 01:20:23 +0100 (CET)

> Il 15 marzo 2019 alle 19.36 Ted Hardie <[email-masked]> ha scritto:
> 
>     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. 
> 
Does anyone have data on this "extremely high"? I am not challenging that the problem exists, though, in my experience of the last couple of years in Europe, the sudden availability of cheap Europe-wide mobile data plans means that people using the Internet from a smartphone tend to use random wi-fi networks less, and to stick to the network of their mobile operator when traveling (I would love to hear about other places).

In any case, what's problematic in that trade-off is the non sequitur that since "trusting the local infrastructure is extremely problematic in nomadic cases" then we design technical solutions that never trust the local infrastructure in any case - or even actively try to circumvent it.

This is just wrong, and does not consider that there are indeed many very common device use cases in which being nomadic is a rare exception (such as my mother's laptop) or does not happen at all (such as a desktop PC on a corporate network).

Perhaps letting the user bless the networks they trust would be a better approach.

Regards,

--

---

From: Brian Dickson <[email-masked]>
Date: Fri, 15 Mar 2019 18:47:05 -0700

This has been an excellent discussion, with lots of insightful analysis,
examples, and great context.

I apologize in advance, but I'd like to pick one particular sentence, to
use for teasing out what I think is a foundational issue:

On Fri, Mar 15, 2019 at 11:37 AM Ted Hardie <[email-masked]> wrote:

>
> This is certainly not the case for all deployments of DoH.
>
>
This is where the distinction between, for example, "normative" vs
"informative" are important terms.

What I think we (the larger "we" in these threads) need to settle, is what
should be the rules (aka "protocol") for what we want or need ALL
deployments of DoH to do; or how they do what they do; or how users control
what the clients do; or how network operators (last mile or otherwise) can
influence/control what DNS protocols and operators can be used.

Some of the issues might be how users are able to know the identities of
DNS operators (e.g. certs for DoT or DoH); how services are offered,
selected, configured, and possibly restricted; and what
jurisdictional/regulatory/legal environments might be applicable to any of
the parties involved.

It's definitely a non-trivial issue, but it needs to be handled in a
comprehensive, cooperative, and inclusive manner.

My preference would be that no DoH operators, or client software, be
deployed in a manner that is deliberately ignorant of or in violation of
policies and laws, even if there may be some particular use cases where no
laws or policies are violated by a particular set of {operator,client}
pairs.

Yes, there may be large swaths of jurisdictions vs users where
non-cooperative operation is necessary. I would (and I believe a
consensus-level of individuals involved in DNS would) prefer that those
modes are only engaged where strictly necessary, and that to the greatest
degree possible,  client and operator implementations are able to recognize
when they are not in those particular places/networks, and block hostile
operation (to prevent exploitation by e.g. malware).

I'm glad we at least have these options now.
Lets work together to ensure the best outcomes are achieved, and that we
avoid situations where "camps" cannot find a middle ground.

Brian

---

From: "Ralf Weber" <[email-masked]>
Date: Sat, 16 Mar 2019 14:22:37 +0100

Moin!

> trade-off, not an act of war against you or any other network operator.
You can not get on a network with at least trusting some of its
infrastructure, be it SLAAC or DHCP (which BTW both carry information
for DNS resolving). The question is where you draw the line and IMHO
DNS or name resolution is a basic network function and not an application
setting.

> desire to see the requests.
Yes and this capability existed in operating systems for some time and
was used by some people. It didn’t cause any concern as if a network for
some reason didn’t want to allow user to use external resolving (which is
the case in pretty much every enterprise network) they could simply block
it. This is not so easy with DoH.

> For a very large number of enterprise
This never was fully true and with more and more bring your on device
requiring this will get harder, so network providers (ISP, enterprises,
my home network ;-) have to have tools to apply their network rules,
or if people don’t want to play by the rules block them.

So long
-Ralf
—--
Ralf Weber

---

From: "John Levine" <[email-masked]>
Date: 17 Mar 2019 14:20:56 -0400

In article <[email-masked]> you write:
>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. 
>> 
>Does anyone have data on this "extremely high"? 

I think it's a regional thing.  In North America, mobile data remains
very expensive, and we use wifi wherever we can.  There T-Mobile and
Google Fi offer phones that switch to wifi more or less seamlessly.

In the EU, I agree that data is cheap enough and fast enough that so
long as you can get a mobile signal, there's little incentive to use
wifi.

R's,
John

---

From: Matthew Pounsett <[email-masked]>
Date: Mon, 18 Mar 2019 20:50:15 -0400

> but dealing with a new class of attack was never likely to be free.

This, again, conflates users with attackers.

I'm going to take a stab at restating the positions of several people in
this thread, Paul included, because it really seems like the argument is
not understood.

I have a relationship with my users and I can control the configuration of
their *known* applications.  I do not have a relationship with the malware
author that is trying to steal their data, and cannot control the
configuration of that (unknown) application.  By running DoT on my borders
and blocking all other DNS and DoT traffic, I can provide privacy for my
users while still preventing malware from doing its thing.  With DoH
available at endpoints that my users want to reach using some other
application, it is orders of magnitude more complex for me to block the
malware while still allowing my users to reach those endpoints.  Phrased
another way, a DoH endpoint at the same IP address as a popular website
gives malware the ability to resolve names I was previously able to
prevent.  The only recourse I know of, if DoH is adopted, is to proxy all
traffic toward that example site (including requiring me to engage in a
MitM decryption attack on my users' web traffic) in order to continue to
prevent that malware from circumventing network security.  And because I
can't predict which web sites will launch their own DoH endpoints, that
means I need to proxy (and decrypt) all web traffic in order to maintain
the same level of security I can today.

Somewhere up-thread it was suggested that there are other reasonable steps
that a network/security operator can take to maintain the controls over
resolution that we have today, but so far I haven't seen them enumerated
anywhere.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Mar 2019 08:50:50 +0100

Matthew

> On 19 Mar 2019, at 01:50, Matthew Pounsett <[email-masked]> wrote:
> 
> Somewhere up-thread it was suggested that there are other reasonable steps that a network/security operator can take to maintain the controls over resolution that we have today, but so far I haven't seen them enumerated anywhere.
> 

I had stated that one can use an MDM to manage the endpoint’s use of DoH.  This doesn’t eliminate the possibility of malware, but does reduce misconfiguration in the enterprise, and provides for some protection against infection by blocking known bad names.

In addition, there’s at least a heuristic for detection: compare data plane activity against ANSWERs.  If you’re seeing activity to addresses that don’t match (modulo some noise), you know an alternate resolver is active on that device.  And while it’s possible for malware to mimic queries to Do53 for Good sites versus what it really wants to access, you start tarnishing the rep of the IP address as and when you detect the problem through other means (AV s/w, honey pots, binary inspection, et al).  That leaves it with cloud providers to sort their wagons.

It might also be possible to whitelist ANSWERs into iptables. I wrote the code for that for a dnscap plugin some years ago, and you could even play with it if you want (it’s on GitHub), but I’m not suggesting it’s a good general answer (it was intended for a very specific use case involving relatively few domains for (hopefully cooperating) IoT devices).  As you point out, it won’t tackle shared IP addresses, and quite frankly, little CPE gear won’t scale with a gazillion iptables entries (I’m not sure big gear would either).

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Tue, 19 Mar 2019 09:10:31 -0400

> It might also be possible to whitelist ANSWERs into iptables. I wrote the code for that for a dnscap plugin some years ago, and you could even play with it if you want (it’s on GitHub), but I’m not…

Link?

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Mar 2019 14:13:26 +0100

> On 19 Mar 2019, at 14:10, Ted Lemon <[email-masked]> wrote:
> 
> On Mar 19, 2019, at 3:50 AM, Eliot Lear <[email-masked] <mailto:[email-masked]>> wrote:

Sure.  It’s my branch off of dnscap.  https://github.com/elear/dnscap <https://github.com/elear/dnscap>.  See plugins/aclm.  Limited doc is available, but anyone who wants to play just let me know.

Eliot

---

From: Christian Huitema <[email-masked]>
Date: Tue, 19 Mar 2019 10:37:08 -0700

On 3/19/2019 12:50 AM, Eliot Lear wrote:
>> On 19 Mar 2019, at 01:50, Matthew Pounsett <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>> Somewhere up-thread it was suggested that there are other reasonable
>> steps that a network/security operator can take to maintain the
>> controls over resolution that we have today, but so far I haven't
>> seen them enumerated anywhere.
>>
>
> I had stated that one can use an MDM to manage the endpoint’s use of
> DoH.  This doesn’t eliminate the possibility of malware, but does
> reduce misconfiguration in the enterprise, and provides for some
> protection against infection by blocking known bad names.

Configuration works well for functions like "phishing protection": the
device users in most cases want some form of protection, and then it is
a matter of how this protection is configured. It does not work so well
for functions like intrusion detection, such as figuring out whether a
device is trying to contact a botnet C&C, because we cannot expect the
infected device to be amenable to configuration.

Third party DNS/DoH providers could probably block resolution of
phishing names or  botnet C&C names using the same methods as
enterprises do today, but the enterprise network will not be informed
that one of its devices just tried to contact a botnet C&C. It would be
very nice if the IETF standardized a way to do that.

>
> In addition, there’s at least a heuristic for detection: compare data
> plane activity against ANSWERs.  If you’re seeing activity to
> addresses that don’t match (modulo some noise), you know an alternate
> resolver is active on that device.  And while it’s possible for
> malware to mimic queries to Do53 for Good sites versus what it really
> wants to access, you start tarnishing the rep of the IP address as and
> when you detect the problem through other means (AV s/w, honey pots,
> binary inspection, et al).  That leaves it with cloud providers to
> sort their wagons.

Yes, one could imagine IP address or IP prefix reputation systems,
similar to the IP address block lists used to protect against spam. This
would work, and it would also provide intrusion detection signals when
an infected device starts contacting a botnet. The problem of course is
the gray line between "blocking phishing sites" and "blocking content
that I disagree with". The various attempts to block the whole of
Wikipedia in order to block some specific pages shows where this can lead.

-- Christian Huitema

---

From: Ted Hardie <[email-masked]>
Date: Tue, 19 Mar 2019 10:44:59 -0700

Hi Matt,

Comments in-line.

On Mon, Mar 18, 2019 at 5:50 PM Matthew Pounsett <[email-masked]> wrote:

> users while still preventing malware from doing its thing.
>

As I said to Paul, I don't think you can if your only defense is blocking
DNS access.  Coding a system to use a non-standard resolution protocol over
TLS is relatively easy; all the malware needs is a specific target to start
at.  That target can be hard coded, derived from the output of a web
search, or produced by the output of an algorithm resident in the malware
and some system-available data (commonly the time).  My apologies if I have
misunderstood your point here, but unless you also block all traffic for
which you have seen no resolution event, I believe that it is entirely
possible to circumvent the defense you describe.

> With DoH available at endpoints that my users want to reach using some
> other application,
>

And this is the critique that is not of DoH as a protocol, but of a
specific deployment possibility.  You've seen the Quad9 folks point and the
Chrome statement of their current deployment plans.  The first said they
will not deploy DNS resources and other web resources on commingled hosts.
The second said that they will only use DoH after a probe reveals that it
is available *at the already configured DNS service*.  This is entirely in
line with Section 3 of RFC 8484:

   A DoH client MUST NOT use a different URI simply because it was
   discovered outside of the client's configuration (such as through
   HTTP/2 server push) or because a server offers an unsolicited
   response that appears to be a valid answer to a DNS query.  This
   specification does not extend DNS resolution privileges to URIs that
   are not recognized by the DoH client as configured URIs.

Browsers do not have an incentive to permit random websites to poison their
caches, so I strongly suspect that there will be no ability to pass a
resolution done in JavaScript down into the browser cache; my experience
during RTCWeb was that the browsers treated all downloaded JavaScript
applications as potentially malign.

> it is orders of magnitude more complex for me to block the malware while
> still allowing my users to reach those endpoints.  Phrased another way, a
> DoH endpoint at the same IP address as a popular website gives malware the
> ability to resolve names I was previously able to prevent.
>

In the RFC 8484 terms, this is a DoH server.  For this threat to be real,
there is an additional requirement:   the DoH server at the popular website
must also be trusted by the application as a source of DNS data.  For the
ones you configure, this remains in your control.  For JavaScript
applications within browsers, see above.  So this is probably the case only
for pure malware, which already has other circumventions available.

> The only recourse I know of, if DoH is adopted, is to proxy all traffic
> toward that example site (including requiring me to engage in a MitM
> decryption attack on my users' web traffic) in order to continue to prevent
> that malware from circumventing network security.  And because I can't
> predict which web sites will launch their own DoH endpoints, that means I
> need to proxy (and decrypt) all web traffic in order to maintain the same
> level of security I can today.
>
> Note that popular Web servers commingling DoH services should answer a DNS
query probe, so you will be able to tell readily if any of them choose to
do it.  And, of course, you could respond by blocking the service rather
than with MitM; I suspect some would.

regards,

Ted

---

From: Eliot Lear <[email-masked]>
Date: Tue, 19 Mar 2019 19:44:55 +0100

Hi Christian,

> On 19 Mar 2019, at 18:37, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
>>> On 19 Mar 2019, at 01:50, Matthew Pounsett <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> Configuration works well for functions like "phishing protection": the device users in most cases want some form of protection, and then it is a matter of how this protection is configured. It does not work so well for functions like intrusion detection, such as figuring out whether a device is trying to contact a botnet C&C, because we cannot expect the infected device to be amenable to configuration.
> 

Yes.

> Third party DNS/DoH providers could probably block resolution of phishing names or  botnet C&C names using the same methods as enterprises do today, but the enterprise network will not be informed that one of its devices just tried to contact a botnet C&C. It would be very nice if the IETF standardized a way to do that.
> 

I don’t see why they wouldn’t, and I could easily envision them being obliged to do so in the future.

> Yes, one could imagine IP address or IP prefix reputation systems, similar to the IP address block lists used to protect against spam. This would work, and it would also provide intrusion detection signals when an infected device starts contacting a botnet. The problem of course is the gray line between "blocking phishing sites" and "blocking content that I disagree with". The various attempts to block the whole of Wikipedia in order to block some specific pages shows where this can lead.

In the enterprise this is not a problem.  In the consumer space, it is a big problem.  This goes back to the fundamental issue of whether or not the user has given meaningful consent and what happens when they do not.  We should be at least mindful of the game of Chicken being played here with governments.  Lessig’s Law is bounded by the fact that governments have a lot more guns than most of us do (with some notable and amusing exceptions).  The point of my message was not to go into this discussion, however, but to talk about what is possible, rather than what is necessarily desirable.

The sharing of threat intel is something that could be reasonably governed by contract in this scenario.  Think about that a bit.

Eliot

---

From: "Winfield, Alister" <[email-masked]>
Date: Tue, 19 Mar 2019 20:53:32 +0000

They say to you IP a.b.c.d which sadly is the external IP on the NAT exiting the corporate network has a problem. So great one of potentially 1000’s of devices is infected but not really much better information than that. In effect exactly what most security operations teams assume is true every day of the week.

Alister Winfield

---

From: Christian Huitema <[email-masked]>
Date: Tue, 19 Mar 2019 17:40:48 -0700

On 3/19/2019 1:53 PM, Winfield, Alister wrote:
>     enterprises do today, but the enterprise network will not be
>     informed that one of its devices just tried to contact a botnet
>     C&C. It would be very nice if the IETF standardized a way to do that.
>
>  
>
> They say to you IP a.b.c.d which sadly is the external IP on the NAT
> exiting the corporate network has a problem. So great one of
> potentially 1000’s of devices is infected but not really much better
> information than that. In effect exactly what most security operations
> teams assume is true every day of the week.
>
That when IPv6 sounds good...

-- Christian Huitema

---

From: Jared Mauch <[email-masked]>
Date: Tue, 19 Mar 2019 21:13:59 -0400

> On Mar 12, 2019, at 5:52 PM, Michael Sinatra <[email-masked]> 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, enterprise or similar.  (The lack
of protection is a side-effect, not a design criteria of making it harder to detect
variation in endpoint behavior)

I don’t support efforts to offer standards that make everything look the same when
they are not the same.

Next someone is going to show up in IDR saying how we must TLS all the routing data
because reasons.  

- Jared

---

From: Jared Mauch <[email-masked]>
Date: Tue, 19 Mar 2019 21:24:33 -0400

> On Mar 15, 2019, at 2:36 PM, Ted Hardie <[email-masked]> wrote:
> 
> 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.  
> 

Once you make all traffic look the same, expect it to be treated the same as possibly malicious by network operators.  

Do you know why software has options like avoid-v4-udp-ports as a config directive?  Expect that to happen regardless of where you move the transport to.

I’m writing this from my own machine that I own, purchased and paid for with my own $$.  If you’re writing from a corporate owned machine, or reading on a corporate owned machine they likely have their own rules for them.  I believe in the open internet, but I also don’t believe in the absolutes people see this in.  You aren’t entitled to all communication in the world.  The IETF can try to carve out a moral high ground that you are referring to.  It may be sound footing, but if you’re in a place where a DNS query for example.com is problematic, one of the solutions is to NOT look up example.com.  It may not be “right” in your mind, but it is a way to prevent being jailed or otherwise which we may both morally agree is the wrong outcome but those other locations that made example.com bad may not care and no writing to/in an IETF WG will change that a single bit.  That change lives outside the IETF WG process.

- Jared

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Mar 2019 01:41:44 +0000

Hiya,

One individualistic data point on this sub-topic, and a real point:

On 20/03/2019 01:13, Jared Mauch wrote:
> identical and you have zero way to protect your home,

I would be happier if my home emitted no cleartext and have
no intention of MITMing any TLS in my home. And that leaves
me with plenty of ways to protect my home network (and as an
aside that is absolutely not the same as protecting my home
at all - such overstatement still doesn't help the discussion).

For example, I discourage use of certain OSes, products and
services, and try help the people using the network to understand
enough about what they're doing to be less than randomly unsafe.
Of course I have some f/w rules and do some monitoring but I
would never use a net-nanny type thing.

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.

And to be clear (but repetitive, sorry;-) my general point is
that my policy is not the only defensible one, just as yours
is not, (even if you claim it is).

And nor is Paul V's - "My network, my rules" can also mean a
much more permissive technical enforcement regime than is
often assumed when hearing such a forceful-sounding catchphrase.
Not all policies need to be enforced technically.

Cheers,
S.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 19 Mar 2019 19:28:28 -0700

Stephen Farrell wrote on 2019-03-19 18:41:
...
> Not all policies need to be enforced technically.

if some of you were wondering why i've grown silent on this thread, this 
is an exemplar.

-- 
P Vixie

---

From: Brian Dickson <[email-masked]>
Date: Tue, 19 Mar 2019 20:17:25 -0700

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

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Mar 2019 03:36:29 +0000

>> unwilling serf-like users.

There's only one problem? Great! :-)

> technical policy enforcement model scales.

My mail was about my policy for my home network and explicitly said
that I do not claim that policy ought be followed by all home networks,
never mind other kinds of network. Your argument about scale is not
therefore relevant. (At least, not unless you want to give up all
argument along the lines of "consider the children.")

My policy, for my network, is as defensible as many others. And that
isn't peculiar to home networks.

> in order to use the network, they are required to agree to the policies.

Wrong. In my home network, my children and their friends have
no real choice to not use the network until they are relatively
economically independent. (And in earlier days, they could not
have given informed consent in any case, being too young.)

In work environments what you say is also not completely correct,
at least in some EU locales, where employees retain rights of
various kinds whilst at work using an employer-provided n/w. We
don't need to argue the rights and wrongs of that, it just is.

> This makes the argument you have above, a vacuously defined one.

Surprising as it may be I disagree that my argument is vacuous:-)

> not employing policies that {you,some people} disagree with.

Ah. You apparently don't understand my non-vacuous argument. I
guess that's better than the opposite:-)

Once more: my policy for my network is defensible but is not
one I claim ought be followed by everyone. And the same applies
for all of the more intrusive policies being espoused here by
those with concerns about DoH. That doesn't mean those concerns
are vacuous or otherwise to be ignored, but does mean that
claims as to such-and-such a policy being a necessity are not
valid. Only one counter-example is needed to demonstrate that,
and I've provided one (that is real, not invented).

S.

---

From: nalini elkins <[email-masked]>
Date: Wed, 20 Mar 2019 09:09:03 +0530

Brian,

Thank you for a thoughtful, well-stated, reasonable comment that seeks to
achieve compromise with the points of view of all being considered.

Nalini

On Wed, Mar 20, 2019 at 8:48 AM Brian Dickson <[email-masked]>
wrote:

> in order to use the network, they are required to agree to the policies..
>
> 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.
>
> 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.
>

-- 
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com

---

From: Brian Dickson <[email-masked]>
Date: Tue, 19 Mar 2019 22:46:28 -0700

> argument along the lines of "consider the children.")

I am saying, that the work product envisioned by participants of the side
meeting,
needs to be some framework that scales, regardless of where it gets used.

It does not matter whether any policy does or does not require scalable
mechanisms.
What does matter is that there exist networks where the mechanisms need to
scale.

What is being envisioned and proposed, is a flexible-enough framework, that
scales.

If something scales, it scales. If it scales, it won't make it impossible
to do what you want, tautologically.

Let's try this using classical logic:

Suppose there is a rule: "A implies B".

The negation of that rule is: "Not B implies Not A".
The negation of that rule is NOT: "Not A implies Not B".

I believe your argument(s) falls into the "Not A implies Not B" category.
(I hope I'm mistaken there.)

However, I am also having a little trouble following your actual meaning.
More below on my challenge with following what you are saying...

> have given informed consent in any case, being too young.)

So, I am trying to understand.
Does their lack of real choice make them unwilling users?
Are you arguing that they should be able to bypass whatever rules you have
for your children?
Do you want your children to be able to undetectably use a third party DNS
resolver, such as DoH, and access naughty networks or malware?
Or do you want to block that particular use case?
I think their category as "unwilling" is mooted by their being minors and
not being able to give informed consent.

In any case, if you do want to give them (all of them or some of them)
access to such third party resolvers, should that not be something
explicitly under your control?
And should it not be easy to do (where I roughly equate "easy to do" with
"scalable", for argument purposes).

> don't need to argue the rights and wrongs of that, it just is.

I think I am also having difficulty with the argument here.

What is the exact scenario (or set of scenarios) you are using in your
example?

Is it an employee located in an EU locale, using a work network?
And is the employee's network applying policies that violate the employees
rights?
If the answer to the second question is "yes", I believe there are many
recourses that do not involve any technology at all, such as civil suits or
whatever mechanisms an employee has under the laws of the EU or their local
jurisdiction.
I think that any proffered mechanism over and above that is largely
redundant, and/or generally within the means of a financially independent
adult to work around, e.g. using a personal device on a mobile network not
provided by the employer.

Or, is the employee's network not applying policies that violate the
employees rights, which I think makes the argument moot, since the
employee's rights are not actually being infringed.

So, yes, the employee has rights, and I don't have any issue with either
the existence of rights, or any opinion on whether that is right or wrong.
What I don't follow from that is, that any network operator using
technology to interfere with those rights, is able to do so with impunity,
and that there is a need to provide mechanisms to bypass that technology.
Is that really the case, currently, in specific jurisdictions? Can you
provide some kind of reference to that, that is verifiable, in the EU?

We all know about the issue with authoritarian regimes, and all that. I
think we can all agree that in those cases, the use of technological
methods to bypass restrictions requires individuals to violate the laws in
those places.
And I am in no way arguing against the technology involved.

I'm saying that outside of those specific jurisdictions/environments, there
is no explicit need for making the privacy technology operate in a strictly
unilateral mode, in such a way as to evade any sort of detection.
I'm saying that it is reasonable to expect that whatever
legally-permissible policies any network operator has, can be enforced
cooperatively between client (software/devices), network(s) (operator(s)),
and server (provider of whatever permitted degree of privacy-enhanced is
permitted by network operators' policies).

The extent of what I'm suggesting is, aside from the authoritarian regime
situation, networks whose policies are not violating local laws (including
whatever "rights" laws may apply), need to be able to implement those
policies in a scalable fashion, including detecting anomalous activity
easily (for e.g. malware detection), and that client software/devices
should be able to, at their discretion, negotiate the maximal privacy
setting desired, including reaching a privacy equivalent of "no networks
available" (don't connect at all).

> those with concerns about DoH.

We (speaking for everyone else) are NOT espousing policies.
We are espousing mechanisms for policy enforcement.
There is a huge difference.
Our position on the enforcement is policy-agnostic.
It doesn't matter what the policies themselves are, the mechanisms need to
scale.
The policies themselves are, honestly, completely out of scope, other than
the mechanics.
If a particular policy is legal in any jurisdiction on this planet, and is
sufficiently well defined and sufficiently distinct from other policies,
the policy framework needs to accommodate it.
There aren't *that* many conceivable policies that apply to DNS in the
intersection spaces of transport protocol (DoH, DoT, TCP, UDP), third party
operators (yes/no), encryption (yes/no), and privacy (yes/no/MITM).

> That doesn't mean those concerns

If it is the EU one, please read above: I don't think it actually does what
you think it does, per se.
If it is the home network one, it isn't about policy, it is about
mechanisms, and your not needing your policy to scale, isn't germane.
If anyone needs the policy framework to scale, that needs to be taken into
consideration.
As long as there is anything close to consensus on the existence of a
non-trivial number of networks who require scalable solutions to this
problem, that should really be the end of it.

I don't understand anyone taking a position that anything doesn't need to
scale, and I think that is what you are saying (from your home network bit.)
Is that really your position?

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 20 Mar 2019 09:27:12 +0000

> needs to be some framework that scales, regardless of where it gets used.

I'm not at all sure about a "framework" being the output. I do
agree that solutions for networks at all scales are required.

> What does matter is that there exist networks where the mechanisms need to

More than one thing matters. That needs to be kept in mind.

> Does their lack of real choice make them unwilling users?

One could describe it that way. I'm sure many kids might do so;-)
But it's not great terminology.

> Are you arguing that they should be able to bypass whatever rules you have

Most of the "rules" are not enforced by computers, and hence don't
need to be written down precisely. For example, I'd encourage them
to not create accounts on web sites. But I don't try enforce that in
any technical way and accept that sometimes they do end up creating
web accounts. Talking to them about what they're doing and scaring
'em that I could snoop if I was bothered are often sufficient.

> resolver, such as DoH,

I don't care about that.

> and access naughty networks 

No, I'd prefer they not. But I have no technical barriers in place
to do such blocking. To the extent that there's a policy at all,
it's defined and (not enforced) purely in the human realm.

> or malware?

Bad question IMO. But in any case, encouraging human behaviour
that doesn't result in malware being executed is IMO more
effective. (E.g. avoiding certain OSes etc.)

> not being able to give informed consent.

As I said neither willing nor unwilling are good descriptive terms
for home network users. They are however quite different from
employees in a corporate network (esp in a case like mine with a
technically permissive policy) and that needs to be recognised.

> explicitly under your control?

I don't care about that.

> "scalable", for argument purposes).

Ease of use is generally good. I think the challenge for e.g.
browsers, will not reside in networks like mine. I do have
some minor split-horizon issues but nothing that'd break badly
for anyone but me and I know how to handle it.

> I think I am also having difficulty with the argument here.

Then feel free to ignore it. My main point is about home networks
but i was responding to how you brought up employees. But in
case it helps...

I'm thinking of the issues that were raised in [1]. The end result
there was that telling employees in advance meant typical corporate
policies were ok, but it's not clear to me if the kind of blocking
we could be discussing here (meaning blocking access to name
resolution) would or wouldn't be considered proportionate, because
it might depend on what services end up being blocked. (IANAL of
course, so I make no claims as to what might happen.)

  [1]
https://www.reuters.com/article/us-privacy-emails-echr/european-court-rules-firms-must-tell-employees-of-email-checks-idUSKCN1BG0YA

> What is the exact scenario (or set of scenarios) you are using in your

It wasn't my example. It was yours:-)

> methods to bypass restrictions requires individuals to violate the laws in

Where there is disagreement is that it's not clear how one could
provide help in that case, but yet allow blocking access to external
recursives in the case of a typical restrictive corporate policy.

> unilateral mode, in such a way as to evade any sort of detection.

It's not clear, to me at least, that what you say there is possible.
But I'm not clear what "unilateral" might mean there.

> We (speaking for everyone else) are NOT espousing policies.

I don't accept that you can speak for everyone else. On what basis
do you say that?

I have seen mails in this discussion asserting that more restrictive
policies do need to be enforced. I hadn't yet seen anyone making such
statements acknowledge that more permissive policies can be as valid.
Hence my bringing up my home network example.

Cheers,
S.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 20 Mar 2019 06:09:36 -0400

> On Mar 19, 2019, at 11:17 PM, Brian Dickson <[email-masked]> wrote:
> 
> 
> 
> On Tue, Mar 19, 2019 at 6:42 PM Stephen Farrell <[email-masked]> wrote:
> 
> Hiya,
> 
> - 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.
> 
> 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.
> 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.
> 

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

---

From: Joe Abley <[email-masked]>
Date: Wed, 20 Mar 2019 12:38:05 +0100

[There is actually a proposal at the bottom of this e-mail. Bear with me.]

On 20 Mar 2019, at 11:09, Jared Mauch <[email-masked]> wrote:

> 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 think what we are seeing is the fundamental tension between privacy and control. You need to give up some privacy in order to make the control possible; you need to give up some control in order to afford privacy.

Some in this thread want certainty that they are able to exercise control, e.g. for devices in their network.

Some in this thread want certainty that they can obtain privacy, e.g. for for their device in any network.

When those people meet, the pitchforks come out. This is already true today; it's not a new DoH problem. I think the balance of the tensions has shifted with the prospect of a change in default behaviour, not because any of this is fundamentally new. The change in defaults tips the power balance (e.g. the balance of cost) between control and privacy. This is Paul's basic point, I think.

Some people seem to be getting worked up about whether the desire for control is more important than the desire for privacy. I don't think that question has an answer, but I think most reasonable people could acknowledge that both positions exist. This is Stephen's basic point, I think.

It's possible today to communicate over covert channels in order to avoid control. This is different from *all* communication happening over covert channels so that no control in the future is possible. That's not how things happen today; that would be a change, a new situation. This is your basic point, I think (that's how I read "scale" in your e-mail, above).

Seems to me that there's a middle ground within sight here.

Standardise this privacy mechanism, and specify (with reasoning) that it should be implemented such that the existence of the channel (but not the content) can be identified as distinct from other traffic by third parties. Maybe specify use of a different port number, as was done with DoT.

Those who choose to ignore that direction and create a covert channel using port 443 instead will do so. Nothing much we can do to stop that today (I guarantee it is already happening). The future is not really different.

Of course when people shift the focus of the conversation from DoH in general to resolverless DNS, and want to interleave DNS messages with HTML and cat GIFs over the same HTTPS bundles, the pitchforks will need to come out again. So keep them handy.

Joe

---

From: Jacques Latour <[email-masked]>
Date: Wed, 20 Mar 2019 17:59:13 +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 <[email-masked]> On Behalf Of Jared Mauch
>Sent: March 20, 2019 6:10 AM
>To: Brian Dickson <[email-masked]>
>Cc: Ted Hardie <[email-masked]>; DoH WG <[email-masked]>; dnsop
><[email-masked]>; paul vixie <[email-masked]>; Michael Sinatra
><[email-masked]>; Stephen Farrell <[email-masked]>
>Subject: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator
>
>
>
>> > 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:
>> - 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.
>>
>> 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.
>>
>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

---

From: Adam Roach <[email-masked]>
Date: Wed, 20 Mar 2019 13:14:32 -0500

On 3/20/19 12:59 PM, Jacques Latour wrote:
> 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

I don't think this second assertion is true in 2019. See if you can make 
even a first-order reasonable guess what I'm accessing at 172.217.1.129 
or 23.227.38.32 or 52.40.19.98 or 216.105.38.15 or 104.20.1.85.

(Hint: I took these all from sites I visit frequently, and none are 
particularly obscure sites)

/a

---

From: 神明達哉 <[email-masked]>
Date: Wed, 20 Mar 2019 11:39:57 -0700

At Wed, 20 Mar 2019 12:38:05 +0100,
Joe Abley <[email-masked]> wrote:

> > 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 think what we are seeing is the fundamental tension between privacy and
control. You need to give up some privacy in order to make the control
possible; you need to give up some control in order to afford privacy.

> Some in this thread want certainty that they are able to exercise
control, e.g. for devices in their network.

> Some in this thread want certainty that they can obtain privacy, e.g. for
for their device in any network.

[...]

Thank you for the nice, concise summary.  I think it's well-balanced
observation of where we are.  (I'm so glad I can finally see a
constructive post after seeing a common pattern of boring IETF
discussion, where people with different opinions just keep stating
their views without making any real progress:).

> Standardise this privacy mechanism, and specify (with reasoning) that it
should be implemented such that the existence of the channel (but not the
content) can be identified as distinct from other traffic by third parties.
Maybe specify use of a different port number, as was done with DoT.

I see that those who want to exercise control can live with this (or
at least using a different set of IP addresses for DoH servers than
those for other ordinary web services).  But I'm not so sure if that's
acceptable for the other group.  In that sense I'm curious whether
some big possible DoH providers are now willing to accept this middle
ground.  If my memory is correct the longer term plan at Google (and
maybe also Clouldflare?) is to provide DoH service on the same IP
addresses as those for other ordinary and popular web services (and on
port 443, of course), so that an intermediate operator cannot easily
block access to their DoH services.

> Those who choose to ignore that direction and create a covert channel
using port 443 instead will do so. Nothing much we can do to stop that
today (I guarantee it is already happening). The future is not really
different.

True.  But I think giant providers tend to respect a community
consensus.  Niche or really malicious players may/will still ignore
it, but it would be very difficult for them to collocate their DoH
services with other important web services that can hardly be blocked,
so it shouldn't be a big problem for "those who want certainty of
control".  So if we can really agree on the above "middle ground" and
publish a BCP or something that describes the consensus, I guess we
can now really work on technical issues.  But I'm not sure if we can
reach that consensus.

--
JINMEI, Tatuya

---

From: Jacques Latour <[email-masked]>
Date: Wed, 20 Mar 2019 19:31:54 +0000

It's not what you access, it's what you block, since reverse DNS is not a good solution in this instance, you need to map the DNS block list to it's IP addresses and block those IPs, and readjust based on TTL, you'll end up blocking more stuff than intended, huge mess, but if you can't trust the DNS to be clean then that's one option to enforce a security policy when browsers are using DoH. This should probably go in draft-livingood-doh-implementation-risks-issues

Jacques

>From: Adam Roach <[email-masked]>
>Sent: March 20, 2019 2:15 PM
>To: Jacques Latour <[email-masked]>; Jared Mauch
><[email-masked]>; Brian Dickson <[email-masked]>
>Subject: Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator
>
>> 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
>
>
>I don't think this second assertion is true in 2019. See if you can make even a
>first-order reasonable guess what I'm accessing at 172.217.1.129 or
>23.227.38.32 or 52.40.19.98 or 216.105.38.15 or 104.20.1.85.
>
>(Hint: I took these all from sites I visit frequently, and none are particularly
>obscure sites)
>
>/a

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 20 Mar 2019 15:45:33 -0400

On Tue, 19 Mar 2019 at 13:37, Christian Huitema <[email-masked]> wrote:

> I had stated that one can use an MDM to manage the endpoint’s use of DoH.
> This doesn’t eliminate the possibility of malware, but does reduce
> misconfiguration in the enterprise, and provides for some protection
> against infection by blocking known bad names.
>
> device users in most cases want some form of protection, and then it is a
> matter of how this protection is configured. It does not work so well for
> functions like intrusion detection, such as figuring out whether a device
> is trying to contact a botnet C&C, because we cannot expect the infected
> device to be amenable to configuration.
>
Yes.  I'm not particularly concerned about cooperative clients.  Even if
it's not possible today, the economics of large enterprises will force
browsers et. al. to make their software configurable in some automated,
mass-update way that works for 50k+ employee companies.  I'll be able to
use the same controls to force cooperative clients to use my resolver,
whether that be DoT or DoH.

It's the uncooperative clients that I'm concerned about, and the presence
of DoH endpoints at the same IP:port pair as other web sites means that in
order to deal with uncooperative clients, operators will have to
block/proxy all external port 443 traffic in order to make sure malware
can't get access to resolution they don't control.

In addition, there’s at least a heuristic for detection: compare data plane
> activity against ANSWERs.  If you’re seeing activity to addresses that
> don’t match (modulo some noise), you know an alternate resolver is active
> on that device.  And while it’s possible for malware to mimic queries to
> Do53 for Good sites versus what it really wants to access, you start
> tarnishing the rep of the IP address as and when you detect the problem
> through other means (AV s/w, honey pots, binary inspection, et al).  That
> leaves it with cloud providers to sort their wagons.
>
> Yes, one could imagine IP address or IP prefix reputation systems, similar
> to the IP address block lists used to protect against spam. This would
> work, and it would also provide intrusion detection signals when an
> infected device starts contacting a botnet. The problem of course is the
> gray line between "blocking phishing sites" and "blocking content that I
> disagree with". The various attempts to block the whole of Wikipedia in
> order to block some specific pages shows where this can lead.
>
The distinction between blocking single pages vs. blocking whole domains
isn't really relevant here since we're talking about DNS-based blocking in
the first place.  However, there's a similar problem between blocking
domain resolution and blocking the IP address a domain resolves to.  Right
now operators can block access to malwareCnC.com even if it resides on the
same web server as useful.website.net because of the way virtual hosting
works.  If operators have to replace their domain reputation feeds with
address reputation feeds there's going to be less fine-grained control and
collateral damage.

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 20 Mar 2019 16:08:26 -0400

On Tue, 19 Mar 2019 at 13:45, Ted Hardie <[email-masked]> wrote:

>
>> I have a relationship with my users and I can control the configuration
>> of their *known* applications.  I do not have a relationship with the
>> malware author that is trying to steal their data, and cannot control the

I think you need to understand a bit of the history of malware development
and the arms race to block it.

Malware C&C started out at hard-coded IP addresses.  They quickly realized
this didn't work because going to a single address for your C&C is easily
spotted, easily filtered, and easily taken down.  So they moved to using
domain names and DNS; they could change the IP addresses that their C&C
domains resolved to very quickly, and move C&C around, avoiding takedown.
After a while, the domain sales business got better at domain takedowns,
and so malware developers moved from single domains to DGAs.  Which is
where we are today.

Using a hard-coded endpoint for domain resolution, even if it's TLS
encrypted, is as easily spotted and dealt with as using a single hard-coded
endpoint for C&C.. it can be filtered as soon as the anomaly is detected.
Using DGAs to bootstrap such hidden resolution systems has the same
limitations as DGAs above.  It's just adding an extra layer of abstraction,
using identical systems, over the C&C in the first place.  The fact that
they are NOT doing this today, even in the face of domain reputation
systems and RPZ feeds should tell you something.  I'd bet any malware
author who's though of doing what you suggest got at most a few dozen lines
into writing the code, realized they were just reimplementing their
existing C&C, and stopped.

> line with Section 3 of RFC 8484:

Quad9 and Chrome's current policies are no guarantee of their future
policies, nor the policies of other major browser developers or web
properties.  I cannot assume a statement made by either organization is
binding on the entire Internet.

When have you ever seen the Internet writ large choose NOT to do a thing
that was enabled by the technology?  The protocol enables (and even
encourages) the deployment possibility, so why shouldn't I expect it?  As
soon as DoH the protocol is in GA codebase of major web browsers there will
immediately be enough uptake on DoH server operation to enable the thing
operators are concerned about.  And remember, the protocol is DESIGNED to
inhibit interference by hiding resolution streams along side other, less
easily blocked traffic.  You seem to be making the argument here, "don't
worry, you'll still be able to interfere with DoH resolution by clients you
don't control."  If so, that is disingenuous at best.

> Browsers do not have an incentive to permit random websites to poison
> their caches, so I strongly suspect that there will be no ability to pass a

As I (and others) have stated several times, browsers aren't the ultimate
problem.  They will be configurable and thus controllable, when they're
cooperative.  It's the uncooperative clients that are the problem, but
they're going to be enabled by adoption by the browsers.

> for pure malware, which already has other circumventions available.

I wish you'd name those other circumventions.  A large part of edge
security these days is predicated on the ability to control malware's
ability to resolve C&C names.

>> Note that popular Web servers commingling DoH services should answer a
> DNS query probe, so you will be able to tell readily if any of them choose
> to do it.  And, of course, you could respond by blocking the service rather

I can't afford to probe every IP address on the planet on a regular basis,
and dynamically modify my blocking based on that.  It's far, far less
expensive to just automatically MitM all web traffic on my network, even
though that is far more expensive than what I have to do today.

---

From: Jared Mauch <[email-masked]>
Date: Wed, 20 Mar 2019 16:33:01 -0400

It’s also about DLP and other related topics. There is a deep well here we keep tiptoeing around. Some things are mitigated by enterprise certificates and others are far more tricky. 

Doing this with DNS helps with that defense in depth. Removing that layer of defense will increase risks on one side while decreasing them on the other. 

You also have a hard time telling employees why you have a MITM box and it reduces your talent pool. 

People here may not worry about it but the insurance carriers for the businesses do. 

Sent from my iCar

> On Mar 20, 2019, at 4:08 PM, Matthew Pounsett <[email-masked]> wrote:
> 
> I can't afford to probe every IP address on the planet on a regular basis, and dynamically modify my blocking based on that.  It's far, far less expensive to just automatically MitM all web traffic on my network, even though that is far more expensive than what I have to do today.

---

From: Matthew Pounsett <[email-masked]>
Date: Wed, 20 Mar 2019 16:33:17 -0400

> [There is actually a proposal at the bottom of this e-mail. Bear with me.]

And it's a good proposal!

> Maybe specify use of a different port number, as was done with DoT.

I think this would alleviate most people's concerns... certainly it deals
wth mine.  I have difficulty believing it is acceptable to pro-DoH
community though, considering the first of the two use-cases defined in the
Introduction of RFC8484: "... preventing on-path devices from interfering
with DNS operations..."

I eagerly welcome the -bis document that removes this statement, and
defines a new port number which DoH traffic SHOULD use.

Those who choose to ignore that direction and create a covert channel using
> port 443 instead will do so. Nothing much we can do to stop that today (I
> guarantee it is already happening). The future is not really different.
>

Indeed.  If everyone above-board is using port 5443 (to pull a number out
of the air) for their DoH traffic, the below-board usage should be about as
visible as any such usage is today.

Of course when people shift the focus of the conversation from DoH in
> general to resolverless DNS, and want to interleave DNS messages with HTML
> and cat GIFs over the same HTTPS bundles, the pitchforks will need to come
> out again. So keep them handy.
>

I don't actually own a pitchfork, but I'll keep my Woodsman's Pal sharp. :)

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 20 Mar 2019 23:05:48 +0100 (CET)

> Il 20 marzo 2019 alle 12.38 Joe Abley <[email-masked]> ha scritto:
> 

This is actually the recommendation in section 4.6 of my draft :-) And I agree, it looks like the only possible and reasonable compromise between the two viewpoints.

Regards,
-- 

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Jacques Latour <[email-masked]>
Date: Thu, 21 Mar 2019 22:02:42 +0000

Plus! 
Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC?  So the local resolver and apps and browsers can go the _appropriate_ name resolution resource(s) using the protocol of choice. That would be much simpler for default configuration in enterprise and ISP.

>From: DNSOP <[email-masked]> On Behalf Of Ralf Weber

>You can not get on a network with at least trusting some of its infrastructure, be
>it SLAAC or DHCP (which BTW both carry information for DNS resolving). The
>question is where you draw the line and IMHO DNS or name resolution is a basic
>network function and not an application setting.
>

---

From: Brian Dickson <[email-masked]>
Date: Thu, 21 Mar 2019 15:29:12 -0700

On Thu, Mar 21, 2019 at 3:03 PM Jacques Latour <[email-masked]>
wrote:

> Plus!
> Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC?  So
> the local resolver and apps and browsers can go the _appropriate_ name
> resolution resource(s) using the protocol of choice. That would be much
> simpler for default configuration in enterprise and ISP.
>
>
I think that is a good starting place for the side meeting discussion.

However, I think a more expressive configuration might be needed, to
actually provide information to clients for them to configure themselves
and/or make decisions.
E.g.: In DHCP, provide one or more of the following kinds of announcements
or assertions:
- ISP does not allow use of DoH to off-net providers (aka DoH:NONE)
- ISP allows use of DoT to off-net providers (aka DoT:ANY)
- ISP provides a DoT server which inspects DNS queries and/or answers, but
does not record or export any information (aka DoT:<IP>,PRIVACY:YES)
- ISP provides a DoH server which inspects DNS queries and/or answers, and
records and exports per user data, keeping data for N days (aka DoH:<IP>,
PRIVACY:NO, RECORD:N)
- ISP provides validating DNSSEC UDP only (aka DNSUDP:<IP>, DNSSEC:VALIDATE)
- ISP provides non-validating DNSSEC UDP, allows TSIG (aka DNSUDP:<IP>,
DNSSEC:NOVALIDATE, TSIG:YES)
- any other relevant stuff (DNS cookies, TCP stateful, all the newest and
shiniest stuff.)

- Then, a client could pick and choose among available options, based on
some kind of pre-configured preferences, like REQUIRE:PRIVACY,
PREFERENCE:DoT,DoH,DNSSEC,DNS, USE:TSIG, BLOCK:RECORD.

I realize, expressiveness adds complexity. However, it does avoid
assumptions and overloading.

The main criteria is agreement on client vs server (i.e. standardize this
stuff), and possibly also add the network as another party involved (for
upstream transit ISP vs local ISP), if they have differing policies for
allowing offsite/third-party DoH or DoT.

Brian

> infrastructure, be

---

From: "John Levine" <[email-masked]>
Date: 21 Mar 2019 18:50:24 -0400

In article <[email-masked]> you write:
>Plus! 
>Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC?

I believe that for DoT, the idea is that the client just probes the
DNS server address on port 853 and uses it if it gets an answer.  I
suppose you could try the same thing on port 443 but that seems
riskier.

R's,
John

---

From: Jim Reid <[email-masked]>
Date: Thu, 21 Mar 2019 23:04:49 +0000

> On 21 Mar 2019, at 22:29, Brian Dickson <[email-masked]> wrote:
> 
>> On Thu, Mar 21, 2019 at 3:03 PM Jacques Latour <Jacques.Latour@cira..ca> wrote:
>> Plus! 

Nope.

It could be a topic for *another* side meeting. But not the one that’s under consideration here. That side discussion is supposed to be about the contents of draft-reid-doh-operator, draft-livingood-doh-implementation-risks-issues and maybe draft-bertola-bcp-doh-clients. And what to do about those drafts.

I’m not so sure a side meeting on DHCP/SLAAC for DoT/DoH discovery is needed -- at least, not yet -- because there is a live discovery draft and work item already in progress in the DoH WG. That would seem to be the most appropriate place to first raise those issues.

---

From: Wes Hardaker <[email-masked]>
Date: Thu, 21 Mar 2019 16:21:31 -0700

Vittorio Bertola <vittorio.bertola=[email-masked]>
writes:

> This is actually the recommendation in section 4.6 of my draft :-) And
> I agree, it looks like the only possible and reasonable compromise
> between the two viewpoints.

Another way of stating the preference ordering:

If DNS privacy is a goal, systems and applications SHOULD use DNS over
TLS to encrypt traffic to their local resolver if possible (unless the
system and application distrusts the local resolver infrastructure).
Failing that, they MAY next use a DNS over TLS connection to a remote,
potentially public, DNS resolver.  Failing that, they MAY send DNS
traffic over an HTTPS connection.

This preserves privacy as desired while still optimizing local caching,
round trip speeds, and falling back to the must tunneling only as
needed.

What no one has convinced me of (personally) is why applications should
default to a single resolver over HTTPS at all times, regardless of
where I am on the planet.

-- 
Wes Hardaker
USC/ISI

---

From: Christian Huitema <[email-masked]>
Date: Fri, 22 Mar 2019 04:40:31 +0100

> On Mar 22, 2019, at 12:21 AM, Wes Hardaker <[email-masked]> wrote:
> 

Maybe we should start by defining DNS Privacy. There are two issues: using an encrypted transport; and, using a DNS resolver trusted to respect the privacy of queries. Both are necessary. One without the other makes little sense.

Much of the debate is on the second point. One position is that users should be forced to trust the DNS resolver provided by the local infrastructure. Another position is that users have the right to apply their own policy and decide which server they will trust, based on some configuration.

-- Christian Huitema

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 22 Mar 2019 08:53:20 +0100 (CET)

> Il 22 marzo 2019 alle 4.40 Christian Huitema <[email-masked]> ha scritto:
> 

I think this is a mischaracterization of the debate, which actually started because of a third position that you don't mention: Mozilla's public statement that in the future they will force (or, at least, make as a default - clarification requests haven't solved the doubt yet) Firefox users to use a remote resolver chosen within a shortlist that they will manage.

There are some people advocating that in some cases people should have to use the local resolver so that the local network can monitor them and apply policies, but that's always been limited to private / corporate / high security networks. I don't think anyone has ever proposed that all users be always required to use a local resolver, full stop; though, if DoH deployment continues this way, I do see some governments - even in Europe - trying to go in that direction, either by mandating the use of in-country resolvers or by passing GDPR-style legislation that requires any global operator to apply national DNS policies when serving their citizen, or be fined for 4% of their revenues.

In the end, I think that everyone should agree on the principle of user choice (which is actually the first recommendation in my draft). There will then be some discussion on whether the local resolver should continue being the silent default or not; though I note that the opposite policy, i.e. letting each application pick its own default resolver, creates a fragmented mess of a network and makes it much harder for the user to implement any practical choice. But anything different than "users are fully in charge as far as they want" is IMHO dangerous and unmanageable.

Regards,
--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 22 Mar 2019 01:33:42 -0700

On Fri, Mar 22, 2019 at 12:53 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> > Much of the debate is on the second point. One position is that users
> should be forced to trust the DNS resolver provided by the local
> infrastructure. Another position is that users have the right to apply
> their own policy and decide which server they will trust, based on some
> configuration.
>
> I think this is a mischaracterization of the debate, which actually
> started because of a third position that you don't mention: Mozilla's
> public statement that in the future they will force (or, at least, make as
> a default - clarification requests haven't solved the doubt yet) Firefox
> users to use a remote resolver chosen within a shortlist that they will
> manage.
>

I'm not sure where you have attempted to clarify this point (I think we've
been clear on this point at
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/)

Regardless of what the default is, users will be able to disable DoH.

-Ekr

---

From: Ray Bellis <[email-masked]>
Date: Fri, 22 Mar 2019 08:40:12 +0000

On 22/03/2019 08:33, Eric Rescorla wrote:

> I'm not sure where you have attempted to clarify this point (I think 
> we've been clear on this point at

Regardless of that, Firefox is banned from my network until such time as 
I see an unequivocal statement that DoH will not be enabled without 
explicit and informed consent of the user and with their explicit choice 
of DoH resolver.

Ray

---

From: "Winfield, Alister" <[email-masked]>
Date: Fri, 22 Mar 2019 08:48:20 +0000

I have to say it but almost certainly Ill stop using any software that choses at any point to silently choose what I mean by the word privacy. (using a large scale American provider fior doh example). This is simple you allow choice but that choice MUST be both visible and explicit on what the choice means in terms of how it affects privacy. No lies and half truths and no defaults changing the risks I know about.

Note, I guarantee certain US organisations are loving the idea that large percentages of worldwide DNS might go to a small number of American companies. Those companies will be receiving little letters and they WILL be forced to silently comply.

Oh and in the general case did anyone weigh up total privacy. That is does this decrease security by removing visibility of bad things such that the likelihood of data breaches and thus privacy invasion is in total far worse than it was before creating the DoH protocol?

Alister

________________________________
From: Doh <[email-masked]> on behalf of Eric Rescorla <[email-masked]>
Sent: Friday, March 22, 2019 8:35 am
To: Vittorio Bertola
Cc: dnsop; DoH WG; Christian Huitema; Wes Hardaker
Subject: [EXTERNAL] Re: [Doh] [DNSOP] New I-D: draft-reid-doh-operator

On Fri, Mar 22, 2019 at 12:53 AM Vittorio Bertola <vittorio.bertola=[email-masked]<mailto:[email-masked]>> wrote:

> Il 22 marzo 2019 alle 4.40 Christian Huitema <[email-masked]<mailto:[email-masked]>> ha scritto:
>

I'm not sure where you have attempted to clarify this point (I think we've been clear on this point at
https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/<https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhacks.mozilla.org%2F2018%2F05%2Fa-cartoon-intro-to-dns-over-https%2F&data=02%7C01%7Calister.winfield%40sky.uk%7C7e9a280a7ea649d80ec408d6aea15daf%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636888405417671655&sdata=it0Fg12iOaBUyYOhwn2KxeUx76UgZhytVtGS%2BmuwXHM%3D&reserved=0>)

-Ekr

--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
--------------------------------------------------------------------

---

From: [email-masked]
Date: Fri, 22 Mar 2019 10:14:34 +0100 (CET)

> https://hacks.mozilla.org/2018/05/a-cartoon-intro-to-dns-over-https/)

Unfortunately this is not clear at all.

The web page at the link above says: "We'd like to turn this on as the
default for all of our users.". Combined with the remaining text on
the web page, the only conclusions I can draw is that

- Mozilla would like to turn on DoH by default, invisible to the user
(the user gets this configuration without making a choice).
- When DoH is turned on, by default Cloudflare will be used as the DoH
provider.

If these conclusions are correct they are precisely why some of us
find the Mozilla/Firefox stance completely unacceptable.

If these are *not* the conclusions we should draw about Firefox and
Mozilla's plans, you badly need to update the web page on the link
above. You could also at the same time clarify whether Firefox will
use DoH resolvers that are on the same IP addresses as other non-DoH
content.

Steinar Haug, AS2116

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Mar 2019 02:14:56 -0700

On Mar 22, 2019, at 09:48, Winfield, Alister
<Alister.Winfield=[email-masked]> wrote:

> Note, I guarantee certain US organisations are loving the idea that large percentages of worldwide DNS might go to a small number of American companies.

I hate to break it to you, but between a tenth and a fifth of
worldwide DNS resolver traffic already goes to a small number of
American companies. There are countries where the proportion is closer
to 100%.

I think we should try to take the geopolitics out of the discussions
in this venue. None of us live in or identify with a country whose
government is perfect. By all means let's consider the merits of
informed choice by sophisticated end users who have concerns about
privacy jurisdictions, but attaching national identity to sides of the
discussion is just a path to jingoism.

Joe

---

From: "Winfield, Alister" <[email-masked]>
Date: Fri, 22 Mar 2019 10:15:23 +0000

Okay sorry perhaps I should put it differently...

Don't overplay the privacy provided by DoH it has no effect on the DNS provider so any hint of 'privacy' should be caveated by stating its only as private as the company and country in which that company is founded, and where it operates servers. This is where the clients behaviour is of interest. If it chooses a company's service without giving the user an explicit choice its potentially setting it to be less 'private' than the local providers DNS.  This is particularly true in the EU and countries that have strong data protection laws.

Note, I'm not actually anti-DoH. I, however,  don't want it oversold, nor do I want the implementation to ignore real impacts and risks. I include here the risk of unintended consequences many of which will end up making the 'bad' you are trying to fix worse than it is now.

Alister

PS: I know that people use google et al already for DNS. This, however, is a protocol that places privacy front and centre, so it's much more important that clients are clear about what privacy its providing and what privacy it can't provide.

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Mar 2019 11:20:23 +0100

On 22 Mar 2019, at 11:15, Winfield, Alister <Alister.Winfield=[email-masked]> wrote:

> Don't overplay the privacy provided by DoH it has no effect on the DNS provider so any hint of 'privacy' should be caveated by stating its only as private as the company and country in which that company is founded, and where it operates servers.

100% agree that any choice by a sophisticated user would be less than full-informed if the endpoint wasn't considered along with the transport between the user and that endpoint.

Joe

---

From: Eliot Lear <[email-masked]>
Date: Fri, 22 Mar 2019 12:01:48 +0100

Hi Wes,

On 22 Mar 2019, at 00:21, Wes Hardaker <[email-masked]> wrote:
> 
> If DNS privacy is a goal, 

It is a goal. It is not the only goal.  There is a tussle here.  Let’s recognize that.

Eliot

---

From: Ted Lemon <[email-masked]>
Date: Fri, 22 Mar 2019 07:14:04 -0400

> suppose you could try the same thing on port 443 but that seems

This is a workaround for the absence of a way that the network can signal that the local resolver speaks DNS-over-TLS.  It would be nice if there were a way to explicitly signal the availability of this functionality, so that the stub resolver didn’t have to probe for it.   I think this is only relevant to DNS-over-TLS, however—I don’t think there’s any reason to use DoH if you trust the local resolver.

---

From: "Normen B. Kowalewski" <[email-masked]>
Date: Fri, 22 Mar 2019 16:37:15 +0100

Hi Jaques, et al.

Tom Pusateri can probably say something on his now expired
https://www.ietf.org/archive/id/draft-pusateri-dhc-dns-driu-00.txt.  

The git commentary at
https://github.com/pusateri/draft-tpwt-dhc-dns-discovery says:
    Ted Lemon made a good argument that DHCP should only be used for
boostrapping initial network 
    parameters and not for full fledged configuration of all network
parameters.

    There was enough consensus that we feel that moving forward with this
work would go against the 
    wishes of the IETF community.

    There still is a need for configuring the ADN in a campus environment
where all of the servers are 
    controlled by the network administrator but a different proposal will
need to be invented. 

I wonder if ALL (including the original) DNS discovery options) fall into
that area or not, and if that 
possibly changed over time, but likely there was a debate that already
explored the topic in dhc

BR, 

Normen 

-----Ursprüngliche Nachricht-----
Von: DNSOP [mailto:[email-masked]] Im Auftrag von John Levine
Gesendet: Donnerstag, 21. März 2019 23:50
An: [email-masked]
Cc: [email-masked]
Betreff: Re: [DNSOP] [Doh] New I-D: draft-reid-doh-operator

>Is anyone looking at adding DoH and DoT servers as part of DHCP/SLAAC?

I believe that for DoT, the idea is that the client just probes the DNS
server address on port 853 and uses it if it gets an answer.  I suppose you
could try the same thing on port 443 but that seems riskier.

R's,
John

---

From: Bill Woodcock <[email-masked]>
Date: Fri, 22 Mar 2019 10:13:58 -0700

> On Mar 22, 2019, at 12:53 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> If DoH deployment continues this way, I do see some governments - even in Europe - trying to go in that direction, either by mandating the use of in-country resolvers…

India has already started down that path, and it looks like the UK may not be all that far behind.

                                -Bill

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Mar 2019 10:26:09 -0700

Ted Lemon wrote on 2019-03-22 04:14:
> ... I don’t think
> there’s any reason to use DoH if you trust the local resolver.

i'd go further, but i won't, here.

instead i'll say, others go further, and say, centralization is nec'y 
for privacy because it sends queries through a blender, so that distant 
authorities or surveillers on the rdns/adns path, cannot tell where the 
original question came from. this whereness of originalness is more 
apparent if one uses an rdns that only serves a small pool of stubs.

i disagree, and i consider the argument absurd, but it's out there. i 
expect that at someone at some point will wake up and notice that this 
is also the privacy profile of ECS, which is not optional for stub users 
-- their rdns either uses it on upstream cache misses, or not.

sending pii to noncontracted parties is dangerous, among other things, 
to privacy (no matter how defined.)

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Mar 2019 10:35:34 -0700

Bill Woodcock wrote on 2019-03-22 10:13:
> 
> 
>> On Mar 22, 2019, at 12:53 AM, Vittorio Bertola
>> <vittorio.bertola=[email-masked]> wrote: If DoH
>> deployment continues this way, I do see some governments - even in
>> Europe - trying to go in that direction, either by mandating the
>> use of in-country resolvers…
> 

all statements made to date by the india and united kingdom governments 
have indicated that their plans to support in-country RDNS will not be 
mandatory, just as canada's (operated by CIRA) is not mandatory.

i think if some country is intelligent enough to realize that america's 
tech companies are seeing an advantageous flow of in-country PII (that 
being the combination of end-user IP addresses and third-party intents 
such as DNS lookups), and that this puts their economy at some risk, 
they should (or perhaps SHOULD or even MUST) compete against ibm, cisco, 
google, and cloudflare in order to keep this PII in-country and subject 
to local law.

it's the only rational defense against this data grab, and i applaud it.

-- 
P Vixie

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 22 Mar 2019 18:26:34 +0000

On 3/22/19, 3:53 AM, "Doh on behalf of Vittorio Bertola" <[email-masked] on behalf of vittorio.bertola=[email-masked]> wrote:

> letting each application pick its own default resolver, creates a fragmented mess of a network 

[JL] Troubleshooting also becomes potentially more complicated. I can't ask a user to run dig or nslookup and tell me what it says, in order to see what DNS response they got, and from what server. I may have to ask which app they used if the app varies from the OS, and then that app would need to have a relatively easy way to run a test query and show the results. To the extent that this is an IoT device, USB-powered hardware 'thing', or some other non-PC/mobile/tablet with a somewhat limited GUI or no GUI, then it becomes more difficult.

---

From: Joe Abley <[email-masked]>
Date: Fri, 22 Mar 2019 11:51:56 -0700

On Mar 22, 2019, at 18:35, Paul Vixie <[email-masked]> wrote:

all statements made to date by the india and united kingdom governments
have indicated that their plans to support in-country RDNS will not be
mandatory, just as canada's (operated by CIRA) is not mandatory.
Others here can speak more authoritatively than me, e.g. because they work
for CIRA and I don't, but as far as I know the recursive DNS service that
CIRA runs is a commercial product that they sell.

https://cira.ca/cybersecurity/firewall

While I am aware CIRA has taken steps to educate people about the privacy
implications of sending traffic across the border, and no doubt follow
their own advice in the way they build and operate their own
infrastructure, I don't believe this product is related to any kind of
government aspiration to constrain or encourage resolver traffic to stay
local.

Joe

---

From: Jared Mauch <[email-masked]>
Date: Fri, 22 Mar 2019 19:59:29 +0100

> On Mar 21, 2019, at 11:29 PM, Brian Dickson <[email-masked]> wrote:
> 
> I realize, expressiveness adds complexity. However, it does avoid assumptions and overloading.
> 
> The main criteria is agreement on client vs server (i.e. standardize this stuff), and possibly also add the network as another party involved (for upstream transit ISP vs local ISP), if they have differing policies for allowing offsite/third-party DoH or DoT.

So my thoughts on this real quick: one of the reasons many people are using centralized services like 8.8.8.8 (for example) is its complex to run these servers properly. 

I’m worried about this additional complexity breaking the camels back, or deployment being relegated to those of us that may have overly complex home networks. 

The options and matrix add in complexity when a simple approach is likely desired or needed. 

The small networks that do not run their own servers won’t change. The medium where it’s on the bubble will further centralize. Is this what is needed in the community?

- Jared

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Mar 2019 12:26:47 -0700

Jared Mauch wrote on 2019-03-22 11:59:
> So my thoughts on this real quick: one of the reasons many people are
> using centralized services like 8.8.8.8 (for example) is its complex
> to run these servers properly.

i think those optics are the motive, as you say.

however, it is not complex, as you also say.

the optics have been encouraged.

they are misleading.

-- 
P Vixie

---

From: Puneet Sood <[email-masked]>
Date: Fri, 22 Mar 2019 18:08:45 -0400

Hello,

There has been much discussion in the IETF lists over the impact of
using DNS-over-HTTPS (DoH) in a network. We would like to clarify the
Google Public DNS position on this topic. The post I am replying to is
particularly relevant since it makes some assumptions about the plans
of the Google Public DNS service.

For future support of a RFC 8484 compliant service, we plan to do the following:
* Serve RFC 8484 compliant DoH from the well known Google Public DNS
anycast IP addresses (e.g. 8.8.8.8) on the standard HTTPS port 443.
* Migrate our existing DoH services to the well known Google Public
DNS anycast IP addresses, including the beta version (at
https://dns.google.com/resolve) and IETF draft version (at
https://dns.google.com/experimental).

The Google Public DNS anycast IP addresses are distinct from the IP
addresses used to host web content for Google properties. This will
allow operators to control access to the Google Public DNS DoH service
on their networks without impeding access to other Google services.

For DoH implementers we want to ensure the same access to our
implementation whether it is a Google product (like the Chrome
browser) or a third-party product. To this end we aim to track IETF
work on standardized ways to detect DoH support by the system-selected
DNS resolver service (like
https://tools.ietf.org/html/draft-ietf-doh-resolver-associated-doh-02
or https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01).

As a core principle, Google Public DNS aims to provide a DNS resolver
that respects our users’ privacy. Towards that goal, we aim to provide
high quality implementations of various DNS transport mechanisms that
our users can use to reach the service. This includes the traditional
UDP and TCP transports as well as DNS-over-TLS and DNS-over-HTTPS that
provide privacy for the user’s communication with a DNS resolver.

-Puneet Sood
TL/Manager for the Google Public DNS team.

PS: I am attending IETF 104 and will be available for face-to-face discussion.

On Wed, Mar 20, 2019 at 2:40 PM 神明達哉 <[email-masked]> wrote:
> acceptable for the other group..  In that sense I'm curious whether

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 22 Mar 2019 22:36:18 +0000

Hiya,

> provide privacy for the user’s communication with a DNS resolver.

That's good to hear.

As I'm sure you know well, in addition to transport security,
things like logging etc. also affect folks' privacy. Not sure
if you're aware of it, but there's an effort to craft BCP-like
text on that broader topic in a draft [1] in the dprive WG. It'd
be great to get your and other public recursive operators' take
on that draft, as some of those issues have also been a cause of
some of the much discussion here;-)

Cheers,
S.

[1] https://tools.ietf.org/html/draft-ietf-dprive-bcp-op-02

---

From: Richard Bennett <[email-masked]>
Date: Fri, 22 Mar 2019 20:48:26 -0600

I like it if you would kindly define “privacy” in the context of “a DNS resolver that protects our users’ privacy.” Does that mean hiding their lookups from ISPs who might want to enter the market for targeted ads while using them for your company’s own purposes, or just protecting user queries made over insecure public Wi-Fi networks from easy snooping? Because there are better ways to do the latter than with a system that opts users into a centralized resolver.

RB

> On Mar 22, 2019, at 4:08 PM, Puneet Sood <puneets=[email-masked]> wrote:
> 
> Hello,
> 

—
Richard Bennett
High Tech Forum <http://hightechforum.org/> Founder
Ethernet & Wi-Fi standards co-creator

Internet Policy Consultant

---

From: Richard Bennett <[email-masked]>
Date: Fri, 22 Mar 2019 20:56:25 -0600

RB

—
Richard Bennett

---

From: Wes Hardaker <[email-masked]>
Date: Fri, 22 Mar 2019 20:11:06 -0700

> It is a goal. It is not the only goal.  There is a tussle here.  Let’s

Sorry, I knew it was a goal...  Just inserted wording to draw attention
to it.  The whole point of this discussion is DNS privacy related.
-- 
Wes Hardaker
USC/ISI

---

From: Jared Mauch <[email-masked]>
Date: Sat, 23 Mar 2019 07:38:49 -0400

> the optics have been encouraged.

I think for you and I it's less complex.  When I discuss things with
smaller ISPs running DNS isn't even on their list of things anymore, similar
to e-mail and other things where to run the service requires some scale.

I've seen some quite large providers be unable to configure some simple
DNS settings properly.  You have to also look no further than the
research that Mark Andrews and others have done about standards compliance.

I don't think it's as hard as it could be, but it's not as easy either.

- Jared

-- 
Jared Mauch  | pgp key available via finger from [email-masked]
clue++;      | http://puck.nether.net/~jared/  My statements are only mine.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 23 Mar 2019 14:07:50 +0100

Bind9 with no config file now does the right recursive thing, including dnssec. Knot and unbound and powerdns will not be far behind. We just need to get the word out, to ISPs, Enterprise, SOHO, and end users of Windows, macosx, Linux, and BSD. The hard part will be iOS and Android, due to the permission model and app stores. Those can be last.

⁣Get BlueMail for Android ​

---

From: Matthew Pounsett <[email-masked]>
Date: Sat, 23 Mar 2019 18:42:00 +0100

On Sat, 23 Mar 2019 at 14:08, Paul Vixie <[email-masked]> wrote:

> Bind9 with no config file now does the right recursive thing, including
> dnssec. Knot and unbound and powerdns will not be far behind. We just need
> to get the word out, to ISPs, Enterprise, SOHO, and end users of Windows,
> macosx, Linux, and BSD. The hard part will be iOS and Android, due to the
> permission model and app stores. Those can be last.
>

There are rumours that Apple is at least considering DANE
implementations[0] for their mobile and desktop browsers.  If that comes to
pass you'll see DNSSEC validation on iOS a lot sooner than you think.
Anyone who has any customer influence with Apple could possibly push them
in that direction... enough large customers pushing might inch them toward
that ledge.

[0]: <
https://lists.dns-oarc.net/pipermail/dns-operations/2019-January/018298.html

---

From: Paul Vixie <[email-masked]>
Date: Sat, 23 Mar 2019 13:30:14 -0700

Stephen Farrell wrote on 2019-03-22 15:36:
> ... in addition to transport security,

a quick look did not show any treatment of logging above-the-recursive 
(cache miss traffic) with anonymization, as being qualitatively (and 
perhaps legally) different from logging below-the-recursive. is there 
room for this kind of thinking to be expressed?

see also:

https://www.farsightsecurity.com/assets/media/download/passive-dns-privacy.pdf

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Sun, 24 Mar 2019 07:02:30 -0700

first, thank you for this statement, and for the policies it describes.

> TL/Manager for the Google Public DNS team.
this position (for google public dns) is inconsistent with the google 
chrome design description here:

Kenji Baheux wrote on 2019-03-23 22:43:
>>     2) What other reasons are you considering when doing DOH instead of DOT
>>     to protect privacy. >
 > We are not considering DOT, just DOH.

this disparity is concerning. for reasons amply described here...

> From: Brian Dickson <[email-masked]>
> Date: Sun, 24 Mar 2019 04:48:27 -0700
> Message-ID: <CAH1iCipSi+kT32d78Pi+hwPNyuw=[email-masked]>
> Archived-At: <https://mailarchive.ietf.org/arch/msg/dnsop/ZKhwanjOyj5YtxzH4QOs8IsPsEs>

...i remain hopeful that google will adopt a DoT support policy for all 
services (such as Public DNS) _and all products_ (such as Chrome).

-- 
P Vixie

---

From: Patrick McManus <[email-masked]>
Date: Sun, 24 Mar 2019 21:43:59 +0100

On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister <Alister.Winfield=
[email-masked]> wrote:

>
> Don't overplay the privacy provided by DoH it has no effect on the DNS
> provider

The major effect of the transport security on the privacy practices of the
provider is that it allows the client to authenticate the provider. Trust
in their privacy practices needs to be establish some other way (and the
best way we have right now is 'out of band' - hopefully that gets better) -
but with DoH you can be confident that you're having a private conversation
with the entity you've decided to trust. That's a pretty big distinction
from port 53. Without that assurance its reasonable to be concerned about
what names you lookup.

This of course applies to local and enterprise configs as well as the cloud
configs contemplated by most of this thread. An enterprise DoH server
expresses and enforces a policy - if an application needs to use that
policy it should be comforted in transport security providing confirmation
that it is doing so rather than reading in whatever might be showing up on
port 53.

---

From: Patrick McManus <[email-masked]>
Date: Sun, 24 Mar 2019 22:04:04 +0100

I want to add one thought to the general argument that goes along the lines
of "I need to enforce a policy on my network, and doh will just encourage
more https interception - we have gotten nowhere."

This argument assumes a scenario where the network is trusted by the
application and can require/achieve host or application configuration.
Indeed - deploying trust anchors to these clients is the only way you're
going to intercept https as the notion of network defined configuration of
"trusted proxies" and the like is consistently rejected by clients. That
seems like the right standard for DNS as well - go ahead and configure a
different policy but do it via an existing authenticated configuration
mechanism like you would use for adding a trust root.

However, rather than adding a root I would suggest that if you're doing
client configuration for network-local DNS policy, that you deploy a DoH
server that enforces that policy and point DoH clients at it through the
various enterprise config mechanisms. It doesn't require any kind of access
that adding a trust root does not. This has the desirable property that the
application can reliably know what server is providing DNS service in a
fully authenticated way. Perhaps in a "my way or the highway" scenario it
will choose the highway. That's fair enough - that should be a real
choice.  When you just intercept 8.8.8.8:53 an informed decision cannot be
made.

Use of non-default trust roots is also a property generally visible to
applications. Most allow it as a matter of user configuration.

-Patrick

---

From: Brian Dickson <[email-masked]>
Date: Sun, 24 Mar 2019 22:31:52 +0100

Sent from my iPhone

>> On Mar 24, 2019, at 9:43 PM, Patrick McManus <[email-masked]> wrote:
>> 
>> 
> 
>> On Fri, Mar 22, 2019 at 11:15 AM Winfield, Alister <Alister.Winfield=[email-masked]> wrote:
>> 
>> Don't overplay the privacy provided by DoH it has no effect on the DNS provider
> 
> The major effect of the transport security on the privacy practices of the provider is that it allows the client to authenticate the provider. Trust in their privacy practices needs to be establish some other way (and the best way we have right now is 'out of band' - hopefully that gets better) - but with DoH

Minor correction: with DoH or DoT ...

> you can be confident that you're having a private conversation with the entity you've decided to trust. That's a pretty big distinction from port 53. Without that assurance its reasonable to be concerned about what names you lookup.
> 
> This of course applies to local and enterprise configs as well as the cloud configs contemplated by most of this thread. An enterprise DoH server

Minor correction: An enterprise DoH and/or DoT server...

> expresses and enforces a policy - if an application needs to use that policy it should be comforted in transport security providing confirmation that it is doing so rather than reading in whatever might be showing up on port 53.

The only point I’m making in the above is there is no meaningful distinction in the privacy, security, or server validation between DoH vs DoT.

There is one important difference, which is that DoT uses a unique port number. This is important for network operators in identifying encrypted DNS traffic, in order to ensure that implementation of security policies for DNS don’t conflict with any other network policies (regardless of what those policies are.)

IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port MUST be used. DoH should only be used with explicit informed user consent, and only when DoT is unavailable. This supports the “dissident” use case, without impacting any other aspects of privacy provided by DoT.

The blocking of DoT to a given provider should be interpreted as an explicit policy. Users should be informed that they may, and very likely will, be violating someone’s policy, if they choose to use DoH in that circumstance, and that they may be violating laws by doing so, and should only do so if they are willing to accept that risk.

There is no reason DoH should be used if DoT works (towards the same DNS provider).

Brian

---

From: Patrick McManus <[email-masked]>
Date: Sun, 24 Mar 2019 22:42:07 +0100

On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <
[email-masked]> wrote:

>
> This is important for network operators in identifying encrypted DNS
> traffic,
>

not all clients acknowledge a network's right to do such things at all
times. And of course it would be useful to tell the difference between
policy and a RST injection attack.

If the client does acknowledge the network has the right to set policy -
then the policy can be set on the client using existing configuration
mechanisms that allow the client to differentiate between authorized
configuration and perhaps less-authorized folks identifying their DNS
traffic. This is well worn ground in the HTTP space.

---

From: Vittorio Bertola <[email-masked]>
Date: Sun, 24 Mar 2019 23:13:58 +0100 (CET)

> Il 24 marzo 2019 alle 22.42 Patrick McManus <[email-masked]> ha scritto:
> 
> 
>     On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson < [email-masked] mailto:[email-masked] > wrote:
> 
>         > > 
> > 
> >         This is important for network operators in identifying encrypted DNS traffic,
> > 
> >     > 
>     not all clients acknowledge a network's right to do such things at all times. And of course it would be useful to tell the difference between policy and a RST injection attack.
> 
>     If the client does acknowledge the network has the right to set policy - then the policy can be set on the client using existing configuration mechanisms that allow the client to differentiate between authorized configuration and perhaps less-authorized folks identifying their DNS traffic. This is well worn ground in the HTTP space.
> 
Let's say I just bought a new smart TV that can browse the Internet, but I don't want my kids to be able to access inappropriate websites from it. Or, let's say I actually like the fact that my operator filters out malware destinations at the DNS level and I want my new TV to have that protection as well.

In today's "plain DNS" world, I choose a DNS resolver that provides that kind of filters for me, I set it up on my router, and my router pushes it to my smart TV via DHCP. What is the "existing configuration mechanism" that allows me to set this policy in the DoH world, i.e. if the TV came equipped with applications preconfigured to use their own remote resolver via DoH?

As a minimum, I would have to open all the applications and configure them one by one to use my desired resolver, and repeat this for every device connected to my network - while in the current situation this is all automated after I configure the resolver once on my router. But applications like Firefox might completely refuse to use the resolver I want, advertised by my router on my behalf, because it does not support DoH, or it does but is not on their list of "trusted resolvers". And Javascript bits in the pages I visit might use DoH to pre-encoded servers without even offering me any configuration.

Regards,

--

---

From: Paul Wouters <[email-masked]>
Date: Sun, 24 Mar 2019 18:25:01 -0400 (EDT)

On Sun, 24 Mar 2019, Brian Dickson wrote:

> There is one important difference, which is that DoT uses a unique port number. This is important for network
> operators in identifying encrypted DNS traffic, in order to ensure that implementation of security policies for
> DNS don’t conflict with any other network policies (regardless of what those policies are.)

The network cannot "ensure" this based on DNS. I can come on to the
network with a DNS cache already, which is the functional equivalent
of me refreshing my personal cache using a sneaky HTTPS connection.
The network can never control my DNS cache. I won't let it.

So while it was perhaps nice that network operators _could_ help in such
a case, it was never a real defense against a smart network "abuser".

> IMNSHO, if both ports are reachable for a given provider of Do*, the DoT port MUST be used. DoH should only be
> used with explicit informed user consent, and only when DoT is unavailable.. This supports the “dissident” use
> case, without impacting any other aspects of privacy provided by DoT.

If the network allows DoT, clearly it does not care about DoH being
used? Since it will also not be able to read DoT to a remote server
like the Quads. So I do not understand what is gained by such a
policy.

Unless you meant "must use a local DoT server first", in which case we
are again shifting the discussion towards when can or should you trust
a network for anything but relaying IP packets. Because then you
basically demand access to my decrypted DNS stream.

Why should I ever use a starbucks DNS server, regardless of whether
I use DoT or DoH or plain 53? On almost every network I connect to,
I only want one service: "relay my (encrypted) IP packets". The rest
of the services I obtain from trusted sources elsewhere, using this
ephemeral network as an insecure transport only.

So your policy above that you propose really assumes a lot about the
network, namely that you are considered hostile to the network and
that you trust that network more than your own device. That's a very
specific application. It basically never applies to me unless I join
an enterprise network with an enterprise device, and then we have
other ways for the enterprise to enforce things on their device.

> The blocking of DoT to a given provider should be interpreted as an explicit policy. Users should be informed
> that they may, and very likely will, be violating someone’s policy, if they choose to use DoH in that
> circumstance, and that they may be violating laws by doing so, and should only do so if they are willing to
> accept that risk.

Again, this is the network operator centric view. There are many hostile
networks that would block DoT just so that they could monetize (legally
or illegally!) from my harvested DNS data. I can assure you the warning
you want to write to users would be very different from the warning I
would want to give those users. Which is why the IETF doesn't do
banners towards endusers.

Besides, why should the network operator have a say about when I want my
device to connect to my remote servers? Do you want my VPN client to
throw the same warning around that it might be against the network
operator's wishes to inspect all my traffic and it might be against the
law to circumvent it? Then you also have to do that for _all_ TLS
connections, and make the internet go back to port 80. Why is there a
different expectation of website content monitoring versus dns content
monitoring? You shouldn't have access to either.

> There is no reason DoH should be used if DoT works (towards the same DNS provider).

If DoT works to dot.nohats.ca, which you cannot decrypt, why do you care
whether I use DoH to that server or not?

Paul

---

From: Olli Vanhoja <[email-masked]>
Date: Mon, 25 Mar 2019 00:18:58 +0100

> As a minimum, I would have to open all the applications and configure them one by one to use my desired resolver, and repeat this for every device connected to my network - while in the current sit…

I think configuring every application, operating system, or platform
to do the filtering is the right way regardless of the existence of
DoH. I wouldn't trust that the opinion given by a DHCP server is what
will be really used by all clients. If you need to check that's what
is really happening, wouldn't it require about the same effort to
configure the parental control features that are already provided by
many vendors. I also believe that's a lot easier thing to do for the
average user.

If you really want a DIY solution, why don't you look into the actual
HTTP(S) traffic and SNIs?

---

From: Brian Dickson <[email-masked]>
Date: Mon, 25 Mar 2019 01:10:10 +0100

> a case, it was never a real defense against a smart network "abuser".
I am trying to keep conversation sub-threads specific to single variables.
In this case, I am interested in policy enforcement mechanisms, not what
the policy is or who it applies to.

The assumption in the above is that the network operator has some policy
(regardless of what it is) that it would like to enforce between some (or
possibly all) hosts, towards encrypted DNS services.
If the operator blocks all DoH, but does something less restrictive for
DoT, then the policies applied on DoT are the ones that have the desired
effect.

Yes, this is network-centric, or more specific, network-security-centric.

>From the perspective of the network policy enforcement, the applicable
rules involve 3-tuples of source, destination, and port 853 (plus TCP but
not UDP). Any such rules, when explicitly applied only to port 853, by
definition have no direct bearing on any destinations for port 443 (HTTPS).
These rules only need to be updated if/when new "permit" rules for new DoT
servers are added. This is a white-list model, which scales very nicely.

However, the blocking of specific DoH servers becomes an absolute
nightmare, in that the network operator needs continuously monitor
information from any number of sources (of various degrees of completeness,
trustworthiness, timeliness, etc), for new DoH servers, along with an
ongoing policy maintenance on (allow vs deny). This is, by its very nature,
a black-list model, which does not scale nicely, and consequently reduces
the overall security, from the perspective of the network operator (or
network security department of the enterprise network).

(See my previous message detailing *why* networks NEED to do this, at least
in the large enterprise.)

Chances are, the network segment you are on does not care one whit about
the DNS cache you have, and probably is happy to let you access whoever you
want for your encrypted DNS service.

I'm willing to wager, in the enterprise environment, they do have an
opinion on what transport they prefer you use for that: DoT.

This is mostly about scalability, and about the ability to detect abnormal
behavior distinct from regular user activity (malware, phishing, and other
use cases.)

> > used with explicit informed user consent, and only when DoT is
> unavailable.. This supports the “dissident” use

It is about scale. If large numbers of users, across a variety of
platforms, all use only DoT, then restrictions about which DoT servers are
permitted can be applied.
Or, alternatively, access to new DoT servers can potentially alert the
appropriate security team(s) to investigate which machines have started
this new behavior, and get an early jump on things if this happens to be a
malware-infected device (for example).

Blocking specific DoT servers (or more typically, blocking all DoT servers
except those white-listed) allows end users to know that this blockage is
deliberate. Users can then make informed decisions about whether to accept
that blockage (e.g. due to enterprise policies, or perhaps ISP policies
where those are allowed according to contract and jurisdictional legal
frameworks), or to take unilateral action to bypass the blockage.

What is gained by preferring DoT over DoH, is scaling on the network
operator side, and clear indication of policy via DoT blocking.

Scaling for network operators is always an indirect win for users -- users
have to pay, directly or indirectly, for situations where technology does
not (and cannot) scale.

> basically demand access to my decrypted DNS stream.

This is orthogonal to the network operators' policy. However, in the
enterprise environment, it may be the case that the local DoT server is the
only one not blocked. I would expect that the existence of that server
would be advertised (through whatever mechanism ends up being standardized,
such as DHCP).

You are correct, that is what the operator of any DoT (or DoH) gets: access
to your decrypted DNS stream.
If DoT access to all other servers is blocked, the choice then becomes, use
the local DoT server, or don't use their network (or perhaps don't use DNS).
This is the exact same situation as when port 53 is restricted,
intercepted, or content-tampered, except it adds DNS-to-client encryption.
Whether the DNS results can be trusted is one question.
Whether the privacy practices of the DNS operator is a separate question.
Both are important.

BTW - the trustworthiness of the responses is something that can be, to a
limited degree, mitigated by client DNSSEC validation, when the DNS zones
the client is interested are DNSSEC signed.

I would argue the lack of client DNSSEC validation is one factor in the
slow uptake of DNSSEC on the part of DNS registrants. Adding DNSSEC client
validation would eliminate that as a factor.

> ephemeral network as an insecure transport only.

I don't see why everyone presumes that using Starbucks' networks is a
right, or the only option available.
I know they operate a lot of wifi networks, but how they do so isn't really
anything users of their networks have a direct say in.
Your argument says a lot more about use of encrypted data transport (e.g.
over VPNs), than it does about DNS.
Can't you just run your DNS queries over your VPNs as well? I don't see a
problem with doing so, at all.

> other ways for the enterprise to enforce things on their device.

I'm making an "IF THEN" argument, without specifically taking any position
on the conditional being evaluated.

Even if there are other ways, the position you are taking is making a
decision on their behalf.
You are expressing the opinion that because there is a specific way
available, that that way is reasonable to propose as the only mechanism
permitted.
I am arguing a position that enterprises are free to choose the mechanisms
they use for enforcing policies.

It should be noted (strongly) that device-side enforcement somehow assumes
the device itself is reasonably trust-worthy.
If the device-side enforcement is the only mechanism, then the scope of
device compromise events is much greater than the device itself.
If the network enforces (with or without device-side enforcement, i.e. it
does not preclude doing both in a belt+suspenders approach) policies, more
control over the impact of device compromise is achieved.
(This is particularly important in the case where data exfiltration over
DNS is attempted by malware using the local device's own available DNS
mechanisms. If DoH is available and not blocked, data exfiltration is
nearly trivial. If DoH is not available, and DoT is only possible to the
enterprise DNS servers, the enterprise is in a position to contain the
situation.)

>
> > The blocking of DoT to a given provider should be interpreted as an
> explicit policy. Users should be informed

So, yes, I actually agree with you in this section.

I'm not saying that bypassing blocks should not be supported by software.
I am saying that bypassing blocks requires a lot of user information, user
consent, and should never be the shipped default for software.
I'm also saying that use of DoH should be the exception, used only when
there is no alternative, in a given scenario.
I'm saying DoH needs to be at least opt-in, never opt-out.

And I believe user preferences should never assume the user is willing to
accept degraded privacy options; the user should be able to provide a list
of acceptable DNS privacy operators, and if none are reachable, have two
options: don't use any other DNS services (and basically, don't use the
network), or explicitly attempt to bypass the mechanisms preventing access
to one of the acceptable DNS operators.

Placing DoT ahead of DoH, does not in any way degrade the connection
privacy if the DoT provider is accessible. It does, however, improve the
network operator's security posture.
Thus, for the user it is "a wash", and for the network operator "a huge
win".
I do not understand why advocating for DoT preference is a contentious
issue, if DoT is available.

> monitoring? You shouldn't have access to either.

That is an issue for network operators' policies, which is really
orthogonal to the mechanisms.

There are legitimate reasons that network operators would want to inspect
(via automated threat mitigation systems) all DNS traffic.
I would find it objectionable if any network operator did anything other
than the above, to DNS traffic.
DNSSEC is one way to keep DNS operators relatively honest, at least on the
"dns lies" front (monetizing NXDOMAIN by replacing NXDOMAIN responses with
forged answers).
Limitations on what network operators are allowed to do is a layer-8 or
layer-9 problem, not directly tied to the mechanisms, and should be treated
as such.

(And yes, I realize VPNs are also problematic from the enterprise
perspective, as they could also be used for data exfiltration -- but that
is why reasonable trade-offs in differentiated restrictions based on
security zones are, or should be, best practices for enterprises.)

On non-enterprise networks, I am pretty sure I don't want to see any of
your traffic, VPN or DNS or anything else.

IMHO, monitoring of dns queries should be divorced from PII, and should not
be routinely logged (especially not with PII), except perhaps on an
aggregate basis. Security monitoring, alerting, and logging, should itself
be restricted access, and safeguards should be put in place to prevent
abuse.

This doesn't change my position on the mechanisms required to permit
scalable security operations at the network level.

> whether I use DoH to that server or not?
The reason I care, is that I want to observe all the DoT connections on a
longitudinal basis. I want to see if/when new DoT servers show up,
especially on names that do not indicate peaceful operation.
And if I see a new DoT server show up with some really random name, in a
place I don't expect my networks' users to be using (like Asia somewhere),
with a very recently obtained free LetsEncrypt certificate, I might want to
block the DoT port toward that server, and possibly block all DoT servers
except for my local DoT server, for that client, so I can inspect the DNS
traffic itself.

Having the ability to limit the inspection of DNS traffic to incident
responses, is not only good for the general user population, but also for
the incident responders. If there is one DNS query flow showing up, it
makes analysis a heckuvalot easier, than sifting through a fire hose of DNS
traffic.

I also expect DoT traffic to be several orders of magnitude lower than
HTTPS traffic, where attempting to distinguish DoH from HTTPS traffic would
have immediate cost implications in flow volume and destination variety.

I care about you using DoT, not because I don't trust you, but because I do
trust you.

Brian

---

From: Brian Dickson <[email-masked]>
Date: Mon, 25 Mar 2019 06:35:19 +0100

Sent from my iPhone

> On Mar 24, 2019, at 10:42 PM, Patrick McManus <[email-masked]> wrote:
> 
> 
>> On Sun, Mar 24, 2019 at 10:31 PM Brian Dickson <[email-masked]> wrote:
>> 

What I find interesting, is that as far as I can tell, everything you wrote applies equally to DoH and DoT, if the transport is the only difference. E.g. Same client browser, same DNS service, accessed via DoH or DoT.

Are you suggesting (or claiming) otherwise, and if so, please elaborate?

Brian

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 25 Mar 2019 08:06:53 +0100 (CET)

On Sun, 24 Mar 2019, Vittorio Bertola wrote:

> In today's "plain DNS" world, I choose a DNS resolver that provides that 
> kind of filters for me, I set it up on my router, and my router pushes it to 
> my smart TV via DHCP. What is the "existing configuration mechanism" that 
> allows me to set this policy in the DoH world, i.e. if the TV came equipped 
> with applications preconfigured to use their own remote resolver via DoH?

We can easily turn this example the other way around.

With Do53 in your TV, your kids can easily fool your TV with their own DHCP 
responses or by intercepting and intefering with the DNS traffic while you're 
at work.

With DoH used in the TV, set to use a trusted server, they can't.

-- 

  / daniel.haxx.se

---

From: Mark Andrews <[email-masked]>
Date: Mon, 25 Mar 2019 18:25:36 +1100

> On 25 Mar 2019, at 6:06 pm, Daniel Stenberg <[email-masked]> wrote:
> 
> With Do53 in your TV, your kids can easily fool your TV with their own DHCP responses or by intercepting and intefering with the DNS traffic while you're at work.
> 
> With DoH used in the TV, set to use a trusted server, they can’t.

Which won’t work if the network is filtering Do53 traffic to non approved servers
or if the TV is manually configured with Do53 or DoT servers and the TV’s configuration
is locked down.  Yes, TV’s do have the ability to lock this part of the configuration
down same as filters on program ratings can be enforced provided the data stream includes
the rating information.

The problem with DoH is that it makes filtering difficult.  That is both a good and
a bad thing depending on your perspective and responsibilities.  It’s a pandora’s box.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742              INTERNET: [email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Mon, 25 Mar 2019 08:52:38 +0100

I'm not pushing against DoT per se in this thread, I am pushing against the
notion that a client has an obligation to the network to provide a clear
channel for traffic analysis and downgrade triggers.

One of the notions presented here is that unauthenticated RST injection
forgery is an acceptable, perhaps in the minds of some even desirable,
signal for DoT to trigger downgrades and, further, that clients are
obligated to create a clear signal to the network to enable this approach.
One issue is that you cannot differentiate this signal between a party you
may want to cooperate with (e.g. your enterprise controller) and an
attacker - that's the nature of an unauthenticated injection. But there are
authenticated enterprise configuration methods available for expressing
policy directly to the client in a trusted way. Indeed my post centered
around the notion of https interception being a necessary outcome of DoH in
the enterprise - my point is basically if you can do https interception
then you are doing enterprise config - consider a config to still do
secured DNS with a server that implements the enterprise policy rather than
doing interception.

And if you do that an enterprise client can, by using its own do{th}
server, also enjoy the benefits of transport security and be confident that
the policy server it intends to use is actually the one in use.

fwiw - there are lots of reasons an http client is going to be interested
in an http substrate beyond just traffic analysis defense. It has the
potential for better overall application responsiveness - by sharing
connections and handshakes with other http data. I don't think that
particular discussion is important to this thread.

On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <[email-masked]>
wrote:

> What I find interesting, is that as far as I can tell, everything you
> wrote applies equally to DoH and DoT, if the transport is the only
> difference. E.g. Same client browser, same DNS service, accessed via DoH or
> DoT.
>

---

From: Brian Dickson <[email-masked]>
Date: Mon, 25 Mar 2019 09:14:44 +0100

On Mon, Mar 25, 2019 at 8:52 AM Patrick McManus <[email-masked]>
wrote:

> I'm not pushing against DoT per se in this thread, I am pushing against
> the notion that a client has an obligation to the network to provide a
> clear channel for traffic analysis and downgrade triggers.
>

Actually, it really is.

At a minimum it needs to be treated as an assertion that is subject to
validation or refutation.

This is a refutation:

The DoH operators who have made public statements (google and cloudflare
are two I am aware of), have specifically indicated that NO OTHER HTTPS
TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.

So, the handshakes and sharing argument is specious at best, and bogus at
worst.

The ONLY difference in browsers doing DoH vs DoT, under the hood, is that
DoT does not require the encoding/decoding of the DNS messages (plus all
the other HTTP overhead).
Both DoT and DoH require DNS messages in wire format be constructed first,
and after whatever decoding, wire format responses processed by the client.

A cursory analysis of the logic -- extra encoding vs no extra encoding --
essentially proves by "the triangle inequality"* that DoH cannot be faster
than DoT when comparing same-client to same-server.

Brian

*(the sum of lengths of two sides is greater or equal to the length of the
third side) In this case two sides are the same length (processing of TLS
and DNS) and the other side is extra processing of HTTP encoding, headers,
etc., and the sum is (HTTP + common path) , compared with (common path).
HTTP is not a zero-cost flow, so HTTP + x > x. QED.

>
> On Mon, Mar 25, 2019 at 6:35 AM Brian Dickson <

---

From: Ian Swett <[email-masked]>
Date: Mon, 25 Mar 2019 04:28:21 -0400

One way DoH may be faster than DoT in the near future is that DoH can go
over HTTP/3 via QUIC and avoid head of line blocking like Do53.

---

From: Brian Dickson <[email-masked]>
Date: Mon, 25 Mar 2019 09:37:09 +0100

> clear channel for traffic analysis and downgrade triggers.

I think it would be better to not combine (and conflate) two or more issues
(which may not be directly related).

Plus, this is approaching a "straw man" argument: the notion of
"obligation".

I might not have been clear enough previously. I am arguing against
obligating client applications to take actions that users have not
explicitly given permission to do.
In this case, the action is: "Use Do{HT} service X".
If X is not on the user's list of Do{HT} providers the user has
selected/configured, then my position is the user MUST be prompted prior to
using X, or absent a user interaction mechanism (UI), then X MUST NOT be
used. This includes the case where X is Do53 (regular DNS), if the user has
selected/configured that Do{HT} is required.

In other words, I am proposing that clients not be built so as to be
susceptible to downgrade attacks (whether by the network operator, or by an
attacker). This is directly analogous to attacks on TLS itself for
downgrading TLS versions or cipher selections. In fact, IMHO, Do{TH} should
take a page from the whole TLS state machine, where the client selects
among the servers' offered parameters, possibly deciding to not complete
the handshake if any of a host of issues are discovered (cert validation,
among others).

> obligated to create a clear signal to the network to enable this approach.

This is a separate issue.
Other than blocking all-but-a-few (or all, or a few) DoT servers, I do not
believe anyone has proposed explicit downgrade triggers. Or do you mean,
when a DoT connection is blocked by e.g. a firewall (or other network
enforcement device), that an RST is generated? I believe the RST requires
sequence number validation before it can be processed by the TCP stack,
which means the entity doing the RST generally needs to be in the data
path. Other than "lucky guess" or "high volume attempts", I don't believe
RST to be a serious threat.

> secured DNS with a server that implements the enterprise policy rather than

I agree that there is a need for both service discovery (local and
pre-selected Do{TH} providers), and service *policy* discovery, ideally
authenticated and secured (subject to provider implementations adhering to
mechanisms to provide secure authenticity proofs).

> the policy server it intends to use is actually the one in use.

I agree with this.

I believe there is widespread interest in solving this problem.

However, I believe there is a need for the solution to this problem being
coordinated between the DoH and DoT groups, seeing as the DNS operators
have a significant interest in both DoT and DoH being served on their
servers, and thus a strong interest in any relevant components (discovery,
validation, etc.) being uniformly specified across both protocols.

It might be worth having an AD/WG discussion on where these should be
developed; it might be better to do in DNSOP, rather than DPRIVE or DOH, or
alternatively spinning up a new, very focused WG for this work (I would not
be in favor of the latter).

Brian

---

From: [email-masked]
Date: Mon, 25 Mar 2019 09:40:05 +0100 (CET)

> TRAFFIC will be shared on the IPv{46} addresses serving Do{HT}.

I have seen such a public statement from Google. Where have you seen a
similar statement from Mozilla/Cloudflare?

I asked for such a statement from Mozilla recently (on this mailing
list). No answer yet.

Steinar Haug, AS2116

---

From: Valentin Gosu <[email-masked]>
Date: Mon, 25 Mar 2019 09:52:01 +0100

> So, the handshakes and sharing argument is specious at best, and bogus at

That may be true for Google and Cloudflare right now. But if I will be
running my own DoH server it would probably be on AWS or compute engine
along with any other website I'm currently running, so the connection
sharing WILL happen.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 25 Mar 2019 09:57:35 +0100

> over HTTP/3 via QUIC and avoid head of line blocking like Do53.

Head of line blocking shouldn't happen on a modern Do53 server.

See RFC 7766 §6.2.1.1

Ray

---

From: Brian Dickson <[email-masked]>
Date: Mon, 25 Mar 2019 10:01:26 +0100

On Mon, Mar 25, 2019 at 9:52 AM Valentin Gosu <[email-masked]>
wrote:

>>> fwiw - there are lots of reasons an http client is going to be
>>> interested in an http substrate beyond just traffic analysis defense. It
>>> has the potential for better overall application responsiveness - by
>>> sharing connections and handshakes with other http data. I don't think that

Okay, that's a useful anecdote/datapoint.

Have you considered whether you will need to operate DoT as well, in case
DoH is blocked from some networks that do not also block DoT?

I.e. fallback from DoH to DoT rather than fall all the way back to Do53?

Brian

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Mar 2019 10:13:28 +0100

Hi,

> On 24 Mar 2019, at 23:25, Paul Wouters <[email-masked]> wrote:
> 

Putting aside legal language, but Brian’s basic notion is that the user can make an informed decision and the network can express its policies, with which the user can agree or not agree (and go elsewhere).  Having the protocol elements to permit this sort of agreement is its own tussle.

Eliot

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 25 Mar 2019 09:25:08 +0000

Hiya,

On 25/03/2019 09:13, Eliot Lear wrote:
> Putting aside legal language, but Brian’s basic notion is that the
> user can make an informed decision and the network can express its
> policies, with which the user can agree or not agree (and go
> elsewhere).  Having the protocol elements to permit this sort of
> agreement is its own tussle.
I see a problem with the above argument. DNS means nothing to
most people, so I can't see how they can ever make the informed
decision you mention.

Cheers,
S.

---

From: Eliot Lear <[email-masked]>
Date: Mon, 25 Mar 2019 10:27:40 +0100

> most people, so I can't see how they can ever make the informed

I view that as a research question (I don’t accept your assertion, but neither can I disprove it).  That is- could a question be formed around local network trust that encompasses this component?  Possibly.

Eliot

---

From: Patrick McManus <[email-masked]>
Date: Mon, 25 Mar 2019 10:31:17 +0100

On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson <[email-masked]>
wrote:

>
>
>>
>> \Other than blocking all-but-a-few (or all, or a few) DoT servers, I do
> not believe anyone has proposed explicit downgrade triggers.
>

that's the downgrade I am referring to

> Or do you mean, when a DoT connection is blocked by e.g. a firewall (or
> other network enforcement device), that an RST is generated? I believe the
> RST requires sequence number validation before it can be processed by the
> TCP stack, which means the entity doing the RST generally needs to be in
> the data path. Other than "lucky guess" or "high volume attempts", I don't
> believe RST to be a serious threat.
>

path manipulation attacks are real. arp attacks.. bootp attacks.. rouge
access points. stingray. all kinds of things. unauthenticated network
packets are just that: unauthenticated. RST (or blackhole) is a good
indication that a path isn't going to work - its not a good indication of
who is expressing that policy (or whether it is a policy at all).

Anyhow - I'm really not trying to amp up this thread.. I just felt that
there were a few relevant points to the discussion that had not been
introduced.

---

From: Patrick McManus <[email-masked]>
Date: Mon, 25 Mar 2019 10:41:48 +0100

> Head of line blocking shouldn't happen on a modern Do53 server.
I've seen this confusion before, so I can clear it up!

Ray is (I believe) referring to the flexible re-ordering of DNS
request-reply pairs of a TCP channel.. similar to HTTP/2 (though with less
flexibility in granularity iirc). That addresses hol-blocking problems due
to the time the server spends building replies.

Ian is (I believe) referring to head of line blocking problems related to
TCP's in-order delivery semantic and packet loss. TCP packet loss will
delay the delivery of received packets if there are outstanding unreceived
lower-numbered packets. If the data in these packets are unrelated (e.g.
different DNS request/reply pairs) - that causes head of line blocking to
the application. That's true of http/2 and RFC7766 (anything tcp based
really). QUIC streams provide a mechanism for identifying which sequences
actually need to have that dependency. DoH with H3 would use separate
streams for separate requests (as different HTTP exchanges are inherently
on different streams).

Its a shame that the term hol blocking is used for both scenarios - it has
caused a lot of confusion.

hth

-Patrick

---

From: Brian Dickson <[email-masked]>
Date: Mon, 25 Mar 2019 10:42:44 +0100

On Mon, Mar 25, 2019 at 10:31 AM Patrick McManus <[email-masked]>
wrote:

>
>
> On Mon, Mar 25, 2019 at 9:37 AM Brian Dickson <

Okay, that's good to know, and I think we are in agreement (i.e. that
inference is a poor substitute for declarations.)

I think that this is an area that needs thought and mechanism development,
possibly aligned with DoT/DoH operation, possibly not (or orthogonal to
them).

Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Mar 2019 11:47:15 +0100

This is equally an argument for doing DNS over DTLS. This would give
similar performance to DoH over QUIC.

---

From: Ray Bellis <[email-masked]>
Date: Mon, 25 Mar 2019 14:26:19 +0100

On 25/03/2019 10:41, Patrick McManus wrote:

> request-reply pairs of a TCP channel.. similar to HTTP/2 (though with 
> less flexibility in granularity iirc). That addresses hol-blocking 
> problems due to the time the server spends building replies.
> 
> Ian is (I believe) referring to head of line blocking problems related 
> to TCP's in-order delivery semantic and packet loss. TCP packet loss 
> will delay the delivery of received packets if there are outstanding 
> unreceived lower-numbered packets. If the data in these packets are 
> unrelated (e.g. different DNS request/reply pairs) - that causes head of 
> line blocking to the application. That's true of http/2 and RFC7766 
> (anything tcp based really). QUIC streams provide a mechanism for 
> identifying which sequences actually need to have that dependency. DoH 
> with H3 would use separate streams for separate requests (as different 
> HTTP exchanges are inherently on different streams).
> 
> Its a shame that the term hol blocking is used for both scenarios - it 
> has caused a lot of confusion.
> 
> hth

Yes, that dh :)

I was indeed talking about DNS message re-ordering, and wasn't aware of 
this particular distinction at the TCP layer itself when compared to QUIC.

thanks,

Ray

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Mar 2019 14:46:36 +0000

> over HTTP/3 via QUIC and avoid head of line blocking like Do53.

It ought to be better to have native DoQ to eliminate the overhead of the
http layer. Dunno whether this should use yet another port (all the
obvious ones are already taken) or use ALPN.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
German Bight, Humber: Northwest 6 or 7, occasionally gale 8 at first,
decreasing 4 or 5. Rough or very rough, becoming moderate later. Showers.
Good.

---

From: Puneet Sood <[email-masked]>
Date: Mon, 25 Mar 2019 15:48:43 +0100

Reposting to the list what I shared with Richard Bennett earlier.

The Google Public DNS privacy policy is at
https://developers.google.com/speed/public-dns/privacy. Maybe I should
have included a link to it in the earlier email. If you have comments
on it, please share.

We are following https://tools.ietf.org/html/draft-ietf-dprive-bcp-op
and have commented on an earlier version.

-Puneet

On Sat, Mar 23, 2019 at 3:48 AM Richard Bennett <[email-masked]> wrote:
> High Tech Forum Founder

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Mar 2019 15:04:41 +0000

> similar performance to DoH over QUIC.

If I understand it correctly, DTLS leaves MTU and fragmentation up to the
application protocol. The DNS has horrible packet size problems, so it
needs a lot more help than DTLS provides. QUIC is much better.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
The Minch: Westerly 4 or 5, backing southwesterly 5 or 6, occasionally 7 later
in north. Rough in far north and in far south, otherwise slight or moderate.
Occasional drizzle. Good, occasionally poor.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Mar 2019 16:16:25 +0100

> needs a lot more help than DTLS provides. QUIC is much better.

Indeed.   My point was simply that this avoids ordering problems, just as QUIC does.   I suspect that it is worth having DNS-over-DTLS; QUIC is great, but based on what I’ve been seeing, quite a lot, and probably not appropriate for a lot of use cases where DNS-over-DTLS would do just fine.

---

From: Tony Finch <[email-masked]>
Date: Mon, 25 Mar 2019 16:13:19 +0000

Ted Lemon <[email-masked]> wrote:
> Indeed.  My point was simply that this avoids ordering problems, just as
> QUIC does.  I suspect that it is worth having DNS-over-DTLS; QUIC is
> great, but based on what I’ve been seeing, quite a lot, and probably not
> appropriate for a lot of use cases where DNS-over-DTLS would do just
> fine.

It isn't so much ordering that is the problem, but not delaying answer B
when answer A suffers packet loss. I'm kind of curious about what the
relative trade-offs might be between DoQ and DoT with a decent SACK
implementation, when there is not much latency between the client and the
resolver. DNS-over-DTLS will need its own application layer retry
strategy. I kind of prefer the idea of DNS being able to re-use a good
off-the-shelf transport protocol rather than doing its own thing.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Irish Sea: West or northwest 4 or 5. Smooth or slight. Showers. Good.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 25 Mar 2019 17:23:17 +0100

It seems like SACK would make the problem less bad in theory, but wouldn’t eliminate the problem.   With DNS-over-DTLS, if a packet is lost, the next packet still gets an immediate answer, because DTLS is a datagram protocol, not a stream protocol.   The retry strategy for DNS-over-DTLS would be the same as DNS-over-UDP, once the Diffie-Hellman shared key has been derived.   So assuming you are using this to communicate to a resolver, there would be an initial handshake that’s extra compared to DNS-over-UDP, and then it would just be DNS-over-UDP until such time as re-keying is needed.

> On Mar 25, 2019, at 5:13 PM, Tony Finch <[email-masked]> wrote:
>

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Mar 2019 00:52:47 -0700

> over HTTP/3 via QUIC and avoid head of line blocking like Do53.
Do53/UDP has no HoL prolem.

nor does Do853/TCP.

only Do53/TCP had an HoL problem, so, it was never widely used, and has 
been replaced by Do853/TCP.

-- 
P Vixie

---

From: tirumal reddy <[email-masked]>
Date: Tue, 26 Mar 2019 09:56:36 +0100

> needs a lot more help than DTLS provides. QUIC is much better.

We had a proposal in our draft
https://tools.ietf.org/html/draft-ietf-dprive-dnsodtls-02#section-9 to
handle fragmentation and reassembly but due to lack of support, it was
removed in the next revision.
If there is renewed interest in DNS-over-DTLS, we can submit a new draft
discussing the fragmentation and reassembly procedure.

Cheers,
-Tiru

---

From: tirumal reddy <[email-masked]>
Date: Tue, 26 Mar 2019 11:31:26 +0100

> Do53/UDP has no HoL prolem.

TCP suffers from network head-of-line blocking.

-Tiru