Subject: Re: [Doh] [dns-privacy] New: draft-bertola-bcp-doh-clients

From: nalini elkins <[email-masked]>
Date: Mon, 11 Mar 2019 08:55:18 +0530

> Similarly, putting DNS in user space allows for immediate adoption of
DNSSEC and privacy enhancements, even when the operating system or the
local network does not support them

At enterprises (banks, insurance, etc) on their internal networks, people
run their own DNS servers which may resolve for both internal and external
sites.

We were recently talking to a Fortune 50 company in the United States about
what might happen you install a version of the browser which uses
DNS-over-HTTPS automatically.  (Clearly, this applies to any variant.)

The questions that the Fortune 50 company architect asked were something
like this:

1. You mean that DNS could be resolved outside my enterprise?

2. So whoever that is that resolves my DNS sees the pattern and frequency
of what sites my company goes to?

3. How do I change this?

I look forward to a discussion on this issue.    There will be at least one
enterprise present in Prague to speak for themselves.  I will see if I can
get others to participate remotely.

It would be good to also discuss how to warn enterprises that this is about
to happen.   I wonder if an announcement via CERT or another group may be
appropriate.

Thanks,
Nalini

On Mon, Mar 11, 2019 at 6:36 AM Christian Huitema <[email-masked]>
wrote:

>
> On 3/10/2019 4:07 PM, Vittorio Bertola wrote:
> > Honestly, I understood it differently - at this point in time they are
> > doing tests on whether their resolver performs better or worse than
> > the system's one, but their announced model is that Firefox will adopt
> > a DoH resolver (though it's unclear how it will be chosen) and it will
> > just use that one. But if people from Mozilla could make a clearer
> > announcement on what their plans currently are, that would be good.
> > Still, most of the issues arise whenever an application, for whatever
> > reason and under any mechanism, starts to use one or more resolvers
> > different than the one set up in the operating system: even if it used
> > more than one, you would still get many of the issues listed in the
> > document (though, if it used more than one at the same time, I think
> > you'd actually also get some new specific issues, so we'd need to add
> > a discussion of this possibility).
>
>
> Your view of operating systems and applications is firmly rooted in
> history, which is another way to say in the past. The evolution in the
> past years points to a systematic deconstruction of that relation, with
> for example virtual machine, containers, or the trend to move network
> stacks out of the operating system and into the application. This is
> pretty obvious for security stacks, but it is also becoming very clear
> with QUIC and transport stacks. There are two big drivers: portability,
> and rapid adoption of innovation. These two drivers apply to DNS just
> like they apply to transport.
>
> Putting QUIC in application space allows for immediate provision of
> innovations like 0-RTT, head-of-queue blocking mitigation, or the better
> crypto of TLS 1.3. Similarly, putting DNS in user space allows for
> immediate adoption of DNSSEC and privacy enhancements, even when the
> operating system or the local network does not support them. That genie
> is not going back in the bottle any time soon.
>
> -- Christian Huitema
>
>
> _______________________________________________
> dns-privacy mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dns-privacy
>

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

---

From: nalini elkins <[email-masked]>
Date: Mon, 11 Mar 2019 09:59:11 +0530

BTW, I am reading the draft Tiru et al just posted on DPRIVE about this
issue to see if we have any comments.

> 4) I am using my work laptop on the enterprise network, and
using application-X

This could be an internal application or on the Internet.

Enterprises have connections to:

- Internal LAN / WAN clients

- "Cloud" (much as I dislike the term) applications

- Business partners

- The Internet

Companies also (validly, in my opinion) wish to know if their employees are
going to fantasyfootballgame.com while they are supposedly doing work and
of course, other sites which people should not be going to during work
time.  If I am paying someone, I expect them to do work that I wish them to
do.

The cloud example gets quite a bit more complex with some architectures
some companies are proposing where there will be a complicated topology on
premises.   Let me check with the enterprise who told me about this & I
will see if I can post the diagram or an explanation of what is planned.
This is a complex problem.

Thank your for your thoughtful consideration of the issues.  Please let me
know if my explanation makes the requirements any clearer.

Nalini

On Mon, Mar 11, 2019 at 9:44 AM Christian Huitema <[email-masked]>
wrote:

>
> On 3/10/2019 8:25 PM, nalini elkins wrote:
> >  > Similarly, putting DNS in user space allows for immediate adoption
> > of DNSSEC and privacy enhancements, even when the operating system or
> > the local network does not support them
> >
> > At enterprises (banks, insurance, etc) on their internal networks,
> > people run their own DNS servers which may resolve for both internal
> > and external sites.
> >
> > We were recently talking to a Fortune 50 company in the United States
> > about what might happen you install a version of the browser which
> > uses DNS-over-HTTPS automatically.  (Clearly, this applies to any
> > variant.)
> >
> > The questions that the Fortune 50 company architect asked were
> > something like this:
> >
> > 2. So whoever that is that resolves my DNS sees the pattern and
> > frequency of what sites my company goes to?
> >
> > 3. How do I change this?
>
>
> There are a bunch of conflicting requirements here, and it would be good
> to tease out the contradictions. Consider the following cases:
>
> 1) I am using my phone, and using application-X.
>
> 2) I am at home, using application-X on my home computer.
>
> 3) I am using Wi-Fi in a hotel, and using application-X.
>
> 4) I am using my work laptop on the enterprise network, and using
> application-X
>
> 5) I am using my work laptop in a hotel, and using application-X
>
> 6) I am using my work laptop on the network of a customer, and using
> application-X.
>
> Today, plenty of people claim the right to control how I use the DNS: my
> phone carrier, my ISP at home, the company that got the contract to
> manage the hotel's Wi-Fi, the IT manager for my company's laptop, the IT
> manager for the company that I am visiting. Out of those, there is just
> one scenario for which the claim has some legitimacy: if the company
> pays for my laptop and own the laptop, yes of course it has a legitimate
> claim to control how I am using it. Otherwise, I, the user, get to
> decide. If I like the application's setting better than the network's
> default, then of course I expect those settings to stick.
>
> -- Christian Huitema
>
>
>
>

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Mar 2019 21:14:02 -0700

On 3/10/2019 8:25 PM, nalini elkins wrote:
>  > Similarly, putting DNS in user space allows for immediate adoption

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Mar 2019 22:24:56 -0700

Christian Huitema wrote on 2019-03-10 21:14:
...
> 6) I am using my work laptop on the network of a customer, and using

this distinction is not useful.

there are two cases.

a user or app trusts its network.

or not.

in the first case, you'll use an RDNS service which is in the set 
(allowed (preferred)). that is, you'll use the server you desire most 
out of the set that your network operator allows you to reach.

in the second case, you'll use a VPN, for all of your traffic, not just 
for DNS, because if you hide your DNS but not the connections which 
result from such hiding, it will add no measurable privacy.

> default, then of course I expect those settings to stick.

this distinction is also false.

if you are using my network, then it makes no difference which of us 
bought you that laptop. you will use the RDNS i allow you to use. RDNS 
is part of the control plane, and i use it for both monitoring and 
control. sometimes that's so that i can see malware beacon to its C&C. 
sometimes that's so that i can institute parental controls.

if you don't like my rules, you should vote with your feet, and not 
visit me. because that is the only choice you will have. (yes, i will be 
part of a major new project to identify and block all DoH services, so 
that behavioural security policies can still work, because you may have 
noticed that the internet has never become MORE secure from new tech, 
but it occasionally becomes LESS secure more slowly because of policy.)

quoting again the salient passage of RFC 8484's self-damning introduction:

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

let me give you advance notice: "i aim to misbehave."[1] that is, _i am 
on-path, and i intend to interfere._ why on earth the IETF decided to 
equate dissidents (of whom there are tens of thousands, all of which 
need full VPN's not just DoH for actual safety) with bots (of which 
there are tens of millions), and set up a war between end users and 
network operators, i will never understand, or try to. now, we fight.

-- 
P Vixie

---

From: nalini elkins <[email-masked]>
Date: Mon, 11 Mar 2019 11:04:59 +0530

Paul,

> (yes, i will be part of a major new project to identify and block all DoH
services, so
> but it occasionally becomes LESS secure more slowly because of policy.)

I would be very interested, if you are so inclined, to hear more of what
you are thinking.   Is this something you can (are willing to) talk about?

It sounds like a very thought-provoking initiative.

Thanks,
Nalini

---

From: Paul Vixie <[email-masked]>
Date: Sun, 10 Mar 2019 23:17:43 -0700

Christian Huitema wrote on 2019-03-10 23:05:
> On 3/10/2019 10:24 PM, Paul Vixie wrote:
> 
>> visit me. because that is the only choice you will have. (yes, i will
>> be part of a major new project to identify and block all DoH services,
>> so that behavioural security policies can still work, because you may
>> have noticed that the internet has never become MORE secure from new
>> tech, but it occasionally becomes LESS secure more slowly because of
>> policy.)
> 
> 
> "Use a VPN, or use the local defaults".

that is not what i said.

> Well, there are plenty of
> in-between.

yes, and i gave examples.

see above.

> You claim the right to impose your rules, because it is "your network".
> Yet you have to define ownership. You are providing network services
> under some contractual terms. There are cases where an imperial network
> can dictate those terms, but there are also many cases in which the
> contractual power of the network is limited  -- thinks like fair access,
> network neutrality, etc. Just claiming an empire does not automatically
> make you the emperor.

my network, my rules. your provider's network, their rules. they are 
more likely to have to follow their government's laws of commerce and 
privacy than i am likely to have to follow mine. but if the rules your 
network operator can make allow you to do what you want, use that 
network. that's invariant, for all networks, and for all instances of you.

-- 
P Vixie

---

From: Christian Huitema <[email-masked]>
Date: Sun, 10 Mar 2019 23:05:52 -0700

> tech, but it occasionally becomes LESS secure more slowly because of

"Use a VPN, or use the local defaults". Well, there are plenty of
in-between. For example, I might be using a web proxy, which is sort of
like a VPN but not quite. Or I might be using some web-RTC application,
which uses something else than DNS to identify my peers. DNS is just one
way to locate servers I want to connect to.

-- Christian Huitema

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Mon, 11 Mar 2019 15:06:53 +0000

Please see inline [TR]

From: dns-privacy <[email-masked]> On Behalf Of nalini elkins
Sent: Monday, March 11, 2019 11:05 AM
To: Paul Vixie <[email-masked]>
Cc: Stephen Farrell <[email-masked]>; [email-masked]; [email-masked]; Christian Huitema <[email-masked]>; [email-masked]; Vittorio Bertola <vittorio.bertola=[email-masked]>; Ackermann, Michael <[email-masked]>
Subject: Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

CAUTION: External email. Do not click links or open attachments unless you recognize the sender and know the content is safe.

________________________________
Paul,

> (yes, i will be part of a major new project to identify and block all DoH services, so

I would be very interested, if you are so inclined, to hear more of what you are thinking.   Is this something you can (are willing to) talk about?

[TR] Enterprise networks are already able to block DoH services, it is causing the DoH client to fallback to clear-text DNS compromising endpoint security and privacy. In draft https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01 we are proposing mechanisms to automatically bootstrap endpoints to discover and authenticate privacy-enabling DNS servers provided by the Enterprise network.

The user also gets to know the privacy preserving data policy by the DNS server and can decide whether to switch to another network or if the user trusts the network and privacy policy, the user can enable strict privacy profile with the privacy enabling DNS server discovered in the Enterprise network itself instead of downgrading to opportunistic privacy profile.

Cheers,
-Tiru

Thanks,
Nalini

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

....

there are two cases.

or not.

--
P Vixie

--
Thanks,
Nalini Elkins
President
Enterprise Data Center Operators
www.e-dco.com<http://www.e-dco.com>

---

From: nalini elkins <[email-masked]>
Date: Mon, 11 Mar 2019 22:56:14 +0530

Tiru,

Thanks for your comments.

> Enterprise networks are already able to block DoH services,

We are also concerned about getting threat intelligence so that would
impact DoH on the Internet.   We are also concerned about being able to
block malware, etc. inside the enterprise.

Thank you for doing your draft.  I look forward to understanding it
better.  I believe it is a good start to address some of our potential
problems.  I am thinking over what the deployment and roll out strategies
might be in various topologies.  I will say more once I have thought it out.

Nalini

On Mon, Mar 11, 2019 at 8:37 PM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> Please see inline [TR]
>
>
>
> *From:* dns-privacy <[email-masked]> *On Behalf Of *nalini
> elkins
> *Sent:* Monday, March 11, 2019 11:05 AM
> *To:* Paul Vixie <[email-masked]>
> *Cc:* Stephen Farrell <[email-masked]>; [email-masked];
> [email-masked]; Christian Huitema <[email-masked]>;
> [email-masked]; Vittorio Bertola <vittorio.bertola=
> [email-masked]>; Ackermann, Michael <
> [email-masked]>
> *Subject:* Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
> ------------------------------
>
> Paul,
>
>
>
> [TR] Enterprise networks are already able to block DoH services, it is
> causing the DoH client to fallback to clear-text DNS compromising endpoint
> security and privacy. In draft
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01 we
> are proposing mechanisms to automatically bootstrap endpoints to discover
> and authenticate privacy-enabling DNS servers provided by the Enterprise
> network.
>
>
>
> The user also gets to know the privacy preserving data policy by the DNS
> server and can decide whether to switch to another network or if the user
> trusts the network and privacy policy, the user can enable strict privacy
> profile with the privacy enabling DNS server discovered in the Enterprise
> network itself instead of downgrading to opportunistic privacy profile.
>
>
>
> Cheers,
>
> -Tiru
>
>
>

---

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

>  > Enterprise networks are already able to block DoH services,
i wonder if everyone here knows that TLS 1.3 and encrypted headers is 
going to push a SOCKS agenda onto enterprises that had not previously 
needed one, and that simply blocking every external endpoint known or 
tested to support DoH will be the cheaper alternative, even if that 
makes millions of other endpoints at google, cloudflare, cisco, and ibm 
unreachable as a side effect?

CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24, which i 
blocked already (before DoH) so that's not a problem. but if google 
decides to support DoH on the same IP addresses and port numbers that 
are used for some API or web service i depend on, that web service is 
going to be either blocked, or forced to go through SOCKS. this will add 
considerable cost to my network policy. (by design.)

-- 
P Vixie

---

From: nalini elkins <[email-masked]>
Date: Tue, 12 Mar 2019 02:13:30 +0530

>needed one

I have, ahem, some familiarity with the enterprises and TLS1.3 issue.
(These
past few years have aged me terribly!)  I frankly feel that we have at the
IETF
a problem with the how we do conflict resolution and the process of
consensus
itself.  In fact, I co-authored a draft on this topic:

https://tools.ietf.org/html/draft-elkschul-conflict-problem-00

I feel that until we fix these fundamental issues, we will find ourselves
in this
place again and again.   The next time will be with QUIC (as Paul points out
in his mention of encrypted headers).  I actually have some suggestions as
to how we might better work with each other.  But, I do not want to
sidetrack
into a much larger issue.

At a minimum, I think that some relatively neutral arbiter, say CERT, might
provide an after the fact impact assessment that certain changes such as
DoH and TLS1.3 will have on enterprises, the home user, and so on.   Of
course, it would be better if such a neutral assessment were done BEFORE
the draft becomes final.

This is similar to what is done in California on ballot initiatives.  When
we get our
voting pamphlet, it tells us for each issue, what impact a pro or con vote
will have
on various aspects such as increased taxes, and so forth.

Nalini

---

From: Brian Dickson <[email-masked]>
Date: Mon, 11 Mar 2019 14:33:38 -0700

(Apologies for top-replying)

I think, from squinting at this a bit, that what is missing is some kind of
policy/service discovery, and coming to some kind of agreement (between
DNSOP and DOH, and any/all other interested parties) on what default
behavior should be (and under what conditions/circumstances), e.g. with
respect to opt-in vs opt-out.

E.g. If the local network operator is giving out addresses using DHCP or
the equivalent, then the presence/absence of DNS options in the answers,
should to some degree dictate (permitted) behavior.
And similarly, having some kind of DoH signaling incorporated in the DHCP
options, would be a sensible analogous mechanism.
E.g. "I will allow you to request DoH using providers X, Y, and Z, but
insist on being a MITM for those connections", or "Go ahead and do DoH to
any of these providers X, Y, Z, but no others", or "DoH is prohibited here,
use DNS", or "You can use DoT to these providers, DoH with me as MITM, or
this DNS resolver, but you can't run your own resolver".

Not sure what other mechanisms might be worth considering as alternatives
(dns-sd of some flavor)...

The mechanisms definitely to be a lot cleaner, more transparent, and
configurable, for both clients, network operators, and possibly DoT/DoH
operators.

(Did we learn nothing from the dial-up ISP early days, with mailing out
physical CD ROMs with phone numbers in lists and browsers included?)

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2019 00:00:13 +0000

(This distribution list is too scattered and diverse. Be
great if some AD or someone just picked one list for this.
In the meantime...)

On 11/03/2019 20:43, nalini elkins wrote:
>  impact assessment that certain changes such as
> DoH and TLS1.3 will have on enterprises,

TLS1.3 will, I expect, noticeably improve security for an awful
lot of enterprises in time.

As for DoH, I wonder has anyone done studies on how split-horizon
names and access patterns leak today?

I don't recall having read that kind of study. I can imagine
many ways in which that kind of stuff would leak. I'd be very
surprised if it never happens. I don't know how often it does.

For names, leaking once is kinda fatal. For access patterns,
I guess one leak exposes an IP address that's interested in a
name (e.g. secret-project.example.com) but more would be
needed for broader access patterns to be exposed to "foreign"
recursives and/or in-band networks.

ISTM that it is quite possible that enterprises that deploy their
own DoH services could potentially reduce such leakage and gain
overall. (I'm assuming here that sensible browser-makers will
end up providing something that works for browsers running in
networks with split-horizon setups before those browsers turn
on DoH as a default at scale.)

Cheers,
S.

---

From: nalini elkins <[email-masked]>
Date: Tue, 12 Mar 2019 07:24:29 +0530

Stephen,

> TLS1.3 will, I expect, noticeably improve security for an awful lot of
enterprises in time.

I am sure you are right.   There is also likely to be quite a bit of pain
ahead for many.  Also,
this is exactly why I propose a neutral observer who might tease out the
nuances.   Or
say something along the lines of "if you do x, you will need to do y".  It
may also be
needed to have subtopics.   And, the pro and con sides could also provide a
writeup.
The write up could also propose transition strategies.

I am trying to make it so that people, including enterprises, can better
decide the merits of the
situation for themselves.

Many people do not have the time, expertise or energy to follow these
discussions which
have gone on for a number of years.  I have also seen assessments of
protocol changes from people
who have "a dog in the hunt" so to speak.  That is, vendors who provide an
assessment which
(shockingly enough) results in their own products (which again shockingly,
cost money) being the best
solution.  There is much hyperbole on all sides of not just the TLS1.3
issue but DoH also.

I compliment the authors of the current drafts on DoH deployment drafts for
good efforts to bring
light to this subject.

Having said that, I would like to see IETF work with a neutral third party,
maybe an academic institution,
or CERT, or someone else help people, including enterprise operators, who
have to make decisions to
implement these protocols and possibly change their architecture
strategies.  Even if we manage to
come to consensus on an IETF draft and create an RFC on DoH deployment,
many enterprises do not
keep up with all RFCs nor do they always have the time to evaluate
everything properly because they
are so busy with the fires of the current day.   I worked for large
enterprises for many years doing network
design and troubleshooting.  I was always extremely busy fighting the
issues of the day.

Enterprises, and many others, do pay attention to what NIST or CERT says.
 Just my 2 cents to try
to find a long term solution to what has been a contentious and exhausting
multi-year set of discussions
for all involved and which seems set to rekindle with DoH.

Nalini

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2019 02:34:09 +0000

On 12/03/2019 01:54, nalini elkins wrote:
> I am sure you are right. 

Great.

> There is also likely to be quite a bit of pain
> ahead for many. 

I don't agree at all about that, despite claims to the
contrary from you and some others. But that topic was debated
at length already. (Seriously, do you expect some other outcome
if you re-start that debate?)

> Also,
> nuances.  

I think that's an outstandingly bad idea. The IETF has no
voting and hence no electorate nor constituency and hence
no identifiable non-voting population from whom ostensibly
neutral observers could be chosen via some (currently
non-existent) IETF process. In addition to be just being a
bad idea, what you appear to be suggesting seems to me like
it'd require fundamental change to the core of the IETF and
to also be entirely off topic for the subject line of this
mail.

S.

> Or

---

From: Eliot Lear <[email-masked]>
Date: Mon, 11 Mar 2019 19:18:38 +0100

Hi Paul,

> On 11 Mar 2019, at 19:12, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> i wonder if everyone here knows that TLS 1.3 and encrypted headers is going to push a SOCKS agenda onto enterprises that had not previously needed one, and that simply blocking every external endpoint known or tested to support DoH will be the cheaper alternative, even if that makes millions of other endpoints at google, cloudflare, cisco, and ibm unreachable as a side effect?

That or it will require a bit more management at the MDM level.  I’m hoping the latter.  And I hope that one output of all of these documents will be a recommendation regarding MDM interfaces.

Eliot

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 11 Mar 2019 22:20:16 +0100 (CET)

On Mon, 11 Mar 2019, Paul Vixie wrote:

> CF has so far only supported DoH on 1.1.1.0/24 and 1.0.1.0/24

If that's what you believe and block, then you're not blocking Cloudflare DoH 
very effectively... =)

-- 

  / daniel.haxx.se

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 11 Mar 2019 14:44:06 -0700

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

> needed one,

I'm pretty familiar with TLS 1.3, but I don't know what this means. TLS 1.3
doesn't generally encrypt headers any more than TLS 1.2 did, except for
the content type byte, which isn't that useful for inspection anyway.
Are you perchance referring to encrypted SNI? Something else?

-Ekr

and that simply blocking every external endpoint known or
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Mar 2019 15:23:42 -0700

That's what they told me.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 12 Mar 2019 05:14:42 +0000

> -----Original Message-----
> From: Stephen Farrell <[email-masked]>
> Sent: Tuesday, March 12, 2019 5:30 AM
> To: Paul Vixie <[email-masked]>; [email-masked]
> Cc: nalini elkins <[email-masked]>; Konda, Tirumaleswar Reddy
> <[email-masked]>; [email-masked]; Ackermann,
> Michael <[email-masked]>; Christian Huitema
> <[email-masked]>; [email-masked]; Vittorio Bertola
> <vittorio.bertola=[email-masked]>
> (This distribution list is too scattered and diverse. Be great if some AD or
> someone just picked one list for this.
> In the meantime...)
> 
> >  impact assessment that certain changes such as DoH and TLS1.3 will
> > have on enterprises,
> 
> As for DoH, I wonder has anyone done studies on how split-horizon names
> and access patterns leak today?
> 
> I don't recall having read that kind of study. I can imagine many ways in
> which that kind of stuff would leak. I'd be very surprised if it never happens.
> I don't know how often it does.
> 
> For names, leaking once is kinda fatal. For access patterns, I guess one leak
> exposes an IP address that's interested in a name (e.g. secret-
> project.example.com) but more would be needed for broader access
> patterns to be exposed to "foreign"
> ISTM that it is quite possible that enterprises that deploy their own DoH
> services could potentially reduce such leakage and gain overall. (I'm
> assuming here that sensible browser-makers will end up providing
> something that works for browsers running in networks with split-horizon
> setups before those browsers turn on DoH as a default at scale.)

If Enterprise network provides a DoT/DoH server, browser should be able to discover and use the Enterprise DoT/DoH server.

-Tiru

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Mar 2019 15:04:23 +0100

Hi,

> On 12 Mar 2019, at 14:11, Winfield, Alister <[email-masked]> wrote:
> 
> MDM is also a red-herring given >90% of devices world-wide aren't managed so anyone talking of MDM riding to the rescue of DoH client configuration is walking around with blinkers on.

Firefox has published a specific policy interface just for this purpose.  I think the point, and perhaps others could correct me, is that the MDM serves as evidence that the owner of the device is authorizing a configuration change.  And the use case I am discussing is the enterprise use case.  Your #s do not take that into account.

> Even inside company networks there are servers not under MDM;

Servers seem an unlikely use of DoH from an application in particular.

> locally developed applications that might in future pull in a DoH resolver;

In that case, the enterprise administrator is aiming the shotgun at his or her own foot.  I propose not to solve that problem, but rather to help them with tools to do the right thing.

> BYOD; visitors; malware and so on.

It is certainly not best practice for visitors to be granted access to internal access; instead they typically are given guest access.

BYOD is a different story.  Here DoH may add pressure on those bringing their own devices to have to place them under MDM control.  That pressure already exists, by the way.  DoH just adds to it.

> So whatever you think a reasonable solution for client configuration has to start with unmanaged clients. That last one malware is why the corporate response may well be 'MITM' the traffic so we can protect the data, people and systems using our network.
> 
> What DoH discovery and presentation looks like is complex issue that will take some discussion. Just one small example, I might want to use the local networks DNS if and only if it provides anti-malware protection and has a reasonable privacy policy but use a static one if not. Or perhaps on a child's device it's okay if there is filtering in place suitable for children.

I have previously written here that meaningful consent (a’la Sasse, Acquisti, et al) is a key issue.  With your example, Alister, you are essentially asking about number of attributes from the DNS server; some of which would have to be ascribed by others rather than simply self-asserted.  And then you have to make all of that information consumable and actionable by a normal person.  Good luck.

Just establishing an operational model in which split DNS is handled correctly will be enough of a challenge, but is worth exploring.

And that is why much of this smells like research to me.  If there are willing partners, I think that would be a great avenue to tread down.

Eliot

> 
> Alister
> 
> On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy" <[email-masked] on behalf of [email-masked]> wrote:
> 
>> From: Eliot Lear <[email-masked]>
>> Sent: Monday, March 11, 2019 11:49 PM
>> <[email-masked]>; [email-masked]; [email-masked];
>> Ackermann, Michael <[email-masked]>; Christian Huitema
>> <vittorio.bertola=[email-masked]>; Stephen Farrell
>> <[email-masked]>
>> Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients
>> 
>> Hi Paul,
>> 
>> tested to support DoH will be the cheaper alternative, even if that makes
>> millions of other endpoints at google, cloudflare, cisco, and ibm unreachable
>> as a side effect?
>> 
>> That or it will require a bit more management at the MDM level.  I’m hoping
>> the latter.  And I hope that one output of all of these documents will be a
>> recommendation regarding MDM interfaces.
> 
>    I don't think MDM is required to use the DoT/DoH servers provided by the local network.
> 
>    -Tiru
> 
>> 
>> Eliot
>    https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&amp;data=02%7C01%7Calister.winfield%40sky.uk%7Cab5faa933f374ae7b72c08d6a6ada348%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636879662059337184&amp;sdata=bba3bapIO3ffilylhoIj0x3zVkHYlNC4Gid96Ybx9Xo%3D&amp;reserved=0
>    --------------------------------------------------------------------
>    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
>    --------------------------------------------------------------------
> 
> 
> 
> 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: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 12 Mar 2019 15:13:49 +0000

Please see inline [TR]

From: dns-privacy <[email-masked]> On Behalf Of Neil Cook
Sent: Tuesday, March 12, 2019 5:14 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: [email-masked]; Vittorio Bertola <vittorio.bertola=[email-masked]>; [email-masked]; Paul Vixie <[email-masked]>; Christian Huitema <[email-masked]>; nalini elkins <[email-masked]>; [email-masked]; Ackermann, Michael <[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

Well until now there has been no discovery mechanism for DoH servers. There is now draft adopted by the DoH WG that proposes a discovery mechanism. However whether browsers actually use it is another question. Hence the draft by VIttorio.

[TR] Discovery alone will not solve the problem, the DoH client needs to trust the discovered DoH servers (see https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-01).

Cheers,
-Tiru

Neil

On 12 Mar 2019, at 06:14, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 12, 2019 5:30 AM
To: Paul Vixie <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: nalini elkins <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Ackermann,
Michael <[email-masked]<mailto:[email-masked]>>; Christian Huitema
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Vittorio Bertola
<vittorio.bertola=[email-masked]<mailto:vittorio.bertola=[email-masked]>>
Subject: Re: [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

project.example.com<http://project.example.com>) but more would be needed for broader access

-Tiru

Cheers,
S.
_______________________________________________
DNSOP mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dnsop

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 12 Mar 2019 15:31:12 +0000

MDM may or may not be acceptable even in Enterprise networks. For instance, today network security services are using ML techniques to identify malware flows without acting as a TLS proxy. MDM is also not an option to secure devices in the home networks, especially consumer IoT devices.

Cheers,
-Tiru

From: dns-privacy <[email-masked]> On Behalf Of Eliot Lear
Sent: Tuesday, March 12, 2019 7:34 PM
To: Winfield, Alister <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [dns-privacy] [EXTERNAL] [Doh] [DNSOP] New: draft-bertola-bcp-doh-clients

Hi,

On 12 Mar 2019, at 14:11, Winfield, Alister <[email-masked]<mailto:[email-masked]>> wrote:

Eliot

Alister

On 12/03/2019, 05:43, "dns-privacy on behalf of Konda, Tirumaleswar Reddy" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

-----Original Message-----
From: Eliot Lear <[email-masked]<mailto:[email-masked]>>
Sent: Monday, March 11, 2019 11:49 PM
To: Paul Vixie <[email-masked]<mailto:[email-masked]>>
Cc: nalini elkins <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>;
Ackermann, Michael <[email-masked]<mailto:[email-masked]>>; Christian Huitema
<[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Vittorio Bertola
<vittorio.bertola=[email-masked]<mailto:vittorio.bertola=[email-masked]>>; Stephen Farrell
<[email-masked]<mailto:[email-masked]>>
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

Hi Paul,

On 11 Mar 2019, at 19:12, Paul Vixie <[email-masked]<mailto:[email-masked]>> wrote:

Tiru,

   -Tiru

Eliot
   _______________________________________________
   dns-privacy mailing list
   [email-masked]<mailto:[email-masked]>
   https://emea01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fdns-privacy&amp;data=02%7C01%7Calister.winfield%40sky.uk%7Cab5faa933f374ae7b72c08d6a6ada348%7C68b865d5cf184b2b82a4a4eddb9c5237%7C0%7C0%7C636879662059337184&amp;sdata=bba3bapIO3ffilylhoIj0x3zVkHYlNC4Gid96Ybx9Xo%3D&amp;reserved=0
   --------------------------------------------------------------------
   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]<mailto:[email-masked]> as attachments. Thank you
   --------------------------------------------------------------------

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 16:36:36 +0100

On Mon, Mar 11, 2019 at 08:55:18AM +0530,
 nalini elkins <[email-masked]> wrote 

> 1. You mean that DNS could be resolved outside my enterprise?

I suggest to explain to this person that it was possible before, as
any malware author discovered.

> of what sites my company goes to?

RFC 7626 :-)

> It would be good to also discuss how to warn enterprises that this
> is about to happen.  I wonder if an announcement via CERT or another
> group may be appropriate.

If people responsible for networks of Fortune 50 company don't know
that it is difficult to stop unwanted communication (except when you
control all the endpoints, or when you airgap your network), then it
is indeed a problem :-)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 16:39:20 +0100

On Sun, Mar 10, 2019 at 10:24:56PM -0700,
 Paul Vixie <[email-masked]> wrote 
 a message of 82 lines which said:

> set up a war between end users and network operators,

Well, the tussle already exists. It does not depend on whether you
like it or not, on whether the IETF approves it or not. When people
have different interests, there is a tussle. What we can hope is to
discuss it in civilized ways. But we cannot make it disappear.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 16:44:37 +0100

On Mon, Mar 11, 2019 at 09:59:11AM +0530,
 nalini elkins <[email-masked]> wrote 
 a message of 231 lines which said:

> Companies also (validly, in my opinion) wish to know if their
> employees are going to fantasyfootballgame.com while they are
> supposedly doing work and of course, other sites which people should
> not be going to during work time.  If I am paying someone, I expect
> them to do work that I wish them to do.

Not all companies work that way. Some evaluate the work done by the
results, not by the time spent at the desk. Please let's not discuss
IETF protocols while assuming that all companies are the same, and
that we have to endorse all their policies.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 16:49:13 +0100

On Sun, Mar 10, 2019 at 11:17:43PM -0700,
 Paul Vixie <[email-masked]> wrote 
 a message of 36 lines which said:

> > Yet you have to define ownership.

> my network, my rules. your provider's network, their rules.

I clearly disagree. If the case of my home network (mine, my rules) is
clear, the case of a corporate network is less clear (an employee is
not a slave, and he/she has rights) and the case of a commercial
Internet access provider is clear in the other direction: a client is
not an employee, and is entitled to a free, open and neutral Internet
access.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 12 Mar 2019 15:50:39 +0000

Hi Eric,

In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and white-list, black-list and grey-list TLS session based on the server identity. In other words, middleboxes are conditionally acting as TLS proxies to specific servers (categorized in the grey-list).
With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS proxy for all the flows.

-Tiru

From: Eric Rescorla <[email-masked]>
Sent: Tuesday, March 12, 2019 3:14 AM
To: Paul Vixie <[email-masked]>
Cc: nalini elkins <[email-masked]>; Konda, Tirumaleswar Reddy <[email-masked]>; [email-masked]; [email-masked]; Ackermann, Michael <[email-masked]>; Christian Huitema <[email-masked]>; [email-masked]; Vittorio Bertola <vittorio.bertola=[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

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

-Ekr

CF has so far only supported DoH on 1.1.1.0/24<http://1.1.1.0/24> and 1.0.1.0/24<http://1.0.1.0/24>, which i

--
P Vixie

_______________________________________________
Doh mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/doh

---

From: Neil Cook <[email-masked]>
Date: Tue, 12 Mar 2019 16:55:11 +0100

> On 12 Mar 2019, at 16:36, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Actually many enterprises (particularly banks etc.) do not allow DNS resolution directly from employee endpoints.

Neil

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 12 Mar 2019 08:58:12 -0700

On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> Hi Eric,
>
>
>
> In TLS 1.2, it is possible for firewalls to inspect the TLS handshake, and
> white-list, black-list and grey-list TLS session based on the server
> identity. In other words, middleboxes are conditionally acting as TLS
> proxies to specific servers (categorized in the grey-list).
>
With TLS 1.3 and encrypted SNI, the middle box now has to act as a TLS
> proxy for all the flows.

It would be most useful not to conflate TLS 1.3 and ESNI.

In ordinary TLS 1.3, the SNI is in the clear but the server cert is not.
However, importantly, even in TLS 1.2, the server certificate is not
verifiable, and therefore is not significantly more trustworthy than SNI.

With ESNI, the SNI is encrypted (hence the name). However, the xpectation
is that enterprises which want to do conditional inspection will disable
ESNI on the client. This should not be problematic as they already need
access to the client to install their own trust anchor.

-Ekr

>
> -Tiru
>
>
>
> *From:* Eric Rescorla <[email-masked]>
> *Sent:* Tuesday, March 12, 2019 3:14 AM
> *Cc:* nalini elkins <[email-masked]>; Konda, Tirumaleswar Reddy
> Ackermann, Michael <[email-masked]>; Christian Huitema <
> [email-masked]>; [email-masked]; Vittorio Bertola
> <vittorio.bertola=[email-masked]>; Stephen Farrell <
> [email-masked]>
> *Subject:* Re: [Doh] [dns-privacy] [DNSOP] New:
> draft-bertola-bcp-doh-clients
>
>
>

---

From: Jim Reid <[email-masked]>
Date: Tue, 12 Mar 2019 16:02:08 +0000

> On 12 Mar 2019, at 15:49, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> the case of a commercial

Stephane, that’s simply not true. A client of an Internet access provider is entitled to the service that they contractually agreed to pay for. Check the small print. Or the T&Cs the next time you use some coffeeshop’s wifi. Even if your ISP offers you “free, open and neutral Internet access” (for some definition of that phrase), I’m pretty sure they’ll drop your service if you were damaging their network or or doing something else that was illegal or otherwise in breach of their T&Cs.

---

From: Neil Cook <[email-masked]>
Date: Tue, 12 Mar 2019 17:13:23 +0100

> On 12 Mar 2019, at 17:01, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> On Tue, Mar 12, 2019 at 04:55:11PM +0100,
> Neil Cook <[email-masked]> wrote 
> a message of 22 lines which said:
> 
> They block UDP/53, which is not the same thing. Malware or
> non-cooperating applications can do name resolution by other means. I
> still do not understand why people have a problem with DoH whch did
> not already exist before with
> my-own-name-resolution-protocol-over-HTTPS.

Sure, but the malware has to go to a specific server which can be identified and blocked. For any companies implementing a “whitelist-only” security-policy, this is straightforward. Even without, these kinds of requests can be spotted as anomalies etc.

This is a different scenario then a DoH server co-located with e.g. youtube.com <http://youtube.com/> or whatever, which is a little harder to block (by design as P. Vixie has pointed out).

Neil

---

From: Jim Reid <[email-masked]>
Date: Tue, 12 Mar 2019 16:14:48 +0000

> On 12 Mar 2019, at 16:01, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> I still do not understand why people have a problem with DoH whch did
> not already exist before with my-own-name-resolution-protocol-over-HTTPS.

It’s a question of scale/ubiquity. These “alterate” resolution tricks have up until now been mostly confined to a small number of clueful people. That is going to change dramatically once the world’s web browsers and other web-based apps start using DoH. More so if those platforms have DoH enabled by default.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 12 Mar 2019 18:01:55 +0100

Hi Tiru,

> On 12 Mar 2019, at 16:31, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 

I agree that MDMs should not be viewed as a panacea.  Just a tool in the box.  But this is why I wrote that text the way I did: there may be other ways to express in some secure way evidence of the owner’s intent.

Eliot

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Mar 2019 11:01:22 -0700

> Stephane, that’s simply not true. A client of an Internet access provider is entitled to the service that they contractually agreed to pay for. Check the small print. Or the T&Cs the next time you…

Jim, you are just providing a different interpretation of "entitled".
Your reading is that the fine print in the ISP contract limits what
users are entitled to do. Stephane is pointing out that customers expect
to be able to freely access whatever Internet resource they want,
regardless of the fine print. Courts have been called to decide that
sort of things, in particular for various "shrink wrap" software
licenses. The results vary. Sometimes the courts let the fine print
stand, some times they treat it as an abuse of power and nullify it.
Which points exactly to Stephane's characterization: it is a tussle.

-- Christian Huitema

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Tue, 12 Mar 2019 05:31:46 +0000

-Tiru

---

From: Neil Cook <[email-masked]>
Date: Tue, 12 Mar 2019 12:43:31 +0100

Neil

> On 12 Mar 2019, at 06:14, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
>> From: Stephen Farrell <[email-masked] <mailto:[email-masked]>>
>> To: Paul Vixie <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
>> Cc: nalini elkins <[email-masked] <mailto:[email-masked]>>; Konda, Tirumaleswar Reddy
>> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Ackermann,
>> Michael <[email-masked] <mailto:[email-masked]>>; Christian Huitema
>> <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>; Vittorio Bertola
>> <vittorio.bertola=[email-masked] <mailto:vittorio.bertola=[email-masked]>>
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>

---

From: "Winfield, Alister" <[email-masked]>
Date: Tue, 12 Mar 2019 13:11:48 +0000

MDM is also a red-herring given >90% of devices world-wide aren't managed so anyone talking of MDM riding to the rescue of DoH client configuration is walking around with blinkers on. Even inside company networks there are servers not under MDM; locally developed applications that might in future pull in a DoH resolver; BYOD; visitors; malware and so on. So whatever you think a reasonable solution for client configuration has to start with unmanaged clients. That last one malware is why the corporate response may well be 'MITM' the traffic so we can protect the data, people and systems using our network.

Alister

    -Tiru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 12 Mar 2019 17:01:41 +0100

---

From: "Ralf Weber" <[email-masked]>
Date: Tue, 12 Mar 2019 17:10:14 +0100

Moin!

On 12 Mar 2019, at 17:01, Stephane Bortzmeyer wrote:

>> Actually many enterprises (particularly banks etc.) do not allow DNS 
>> resolution directly from employee endpoints.
>
> They block UDP/53, which is not the same thing.
Well the DNS protocol has been defined on UDP and TCP port 53, so if you 
block this, you block DNS. If you add TCP/853 into the mix you block DNS 
over TLS, all of which is relative easy for an enterprise to do.

> Malware or
A malware doing something specific to it is different than an IETF 
standard and application providers taking this standard (DoH) to switch 
a basic internet function (name lookups) without the users consent which 
are due to using HTTPs/443 harder to block for enterprises. It is a 
pretty clear difference.

So long
-Ralf
—--
Ralf Weber

---

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

On Monday, 11 March 2019 18:18:38 UTC Eliot Lear wrote:
...
> > millions of other endpoints at google, cloudflare, cisco, and ibm

MDM is a cooperation protocol. that is, both the operator and the app or user 
have to want data management to be be mastered (DM to be M, so, MDM).

this is off-topic for DoH, which seeks to prevent on-path interference with 
DNS operations. that is, someone or something using DoH cannot be expected to 
seek cooperation with the network operator.

teenagers and malware being two easy examples. BYOD being another.

pre-DoH, it was possible to ensure that noncompliance with MDM would yield 
failures. that is, disallowing outbound 53 and 853 except from the operator's 
own name servers. post-DoH, such enforcement is (deliberately) impossible.

can we therefore please stop talking about MDM here.

vixie

---

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

> Are you perchance referring to encrypted SNI? Something else?

yes, i mean encrypted SNI, and i apologize for saying "encrypted headers".

> encrypted SNI, an extension to the TLS 1.3 protocol that improves privacy of
> Internet users by preventing on-path observers, including ISPs, coffee shop
> owners and firewalls, from intercepting the TLS Server Name Indication
> (SNI) extension and using it to determine which websites users are
> visiting.

(https://blog.cloudflare.com/encrypted-sni/)

what this means is, if someone is concerned that some of the web sites 
reachable through some CDN are dangerous, they can no longer operate a mostly-
transparent edge gateway, to permit or forbid transactions on a case by case 
basis. rather, they will have to use SOCKS or similar, and blackhole the CDN 
from being reached other than from the SOCKS/similar proxy.

this significantly increases policy enforcement costs, probably placing them 
outside the budget of most small/medium companies, and all home networks.

> Enterprise networks are already able to block DoH services,

that's old-think.

vixie

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Mar 2019 11:56:05 -0700

On 3/12/2019 11:35 AM, Paul Vixie wrote:

> if someone is concerned that some of the web sites 
> reachable through some CDN are dangerous...

Paul, who is this someone? How do they decide? What does dangerous mean?
These questions are very much behind the tension we see today. And the
answers are not as black and white as "this is my network, I get to decide".

For example, users routinely delegate the filtering decision to some
kind of security software running on their device, often with support
from some cloud based service. They are making an explicit decision, and
often use menu options to decide what type of site is OK or not --
adults would probably not subscribe to parental control services. There
is a market for these products, they compete based on reputation, ease
of use, etc.

You are saying that whoever happens to control part of the network path
is entitled to override the user choices and impose their own. Really?
As Stephane wrote, that may be legit in some circumstances, but much
more questionable in others, such as a hotel Wi-Fi attempting to decide
what sites I could or could not access. It really is a tussle.

-- Christian Huitema

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Mar 2019 19:33:47 +0000

> any malware author discovered.

no, it was not possible before. or rather, it could be cheaply prevented 
before.

> control all the endpoints, or when you airgap your network), then it

in my own travels, i've met some fortune-level CISO's who had not yet been 
told that RDNS monitor/control bypass was now an internet standard, and that 
behavioural modeling based on TCP/443 endpoints was no longer practical. so, i 
urge greater efforts on getting the word out.

vixie

---

From: Michael Sinatra <[email-masked]>
Date: Tue, 12 Mar 2019 13:29:30 -0700

> It’s a question of scale/ubiquity. These “alterate” resolution tricks have up until now been mostly confined to a small number of clueful people. That is going to change dramatically once the world…

There's also a fundamental tension that arises when we define as
legitimate those practices that are indistinguishable (or hard to
distinguish) from what bad guys do.  Think of all of the HR departments
out there that send *legitimate* emails asking their employees to click
on a link to update/verify information.  DoH does this too and it
arguably goes a step further by effectively obfuscating DNS resolution
activity, so that legitimate users occupy the same "hideout" as the bad
guys.

This is one of the main themes of section 9 of draft-reid-doh-operator
and one of the main motivations in the recommendations of section 4 of
draft-bertola-bcp-doh-clients, but it bears restating because for those
of us trying to do risk mitigation, or even policy compliance, DoH gives
us additional headaches.

michael

---

From: "Yishai Beeri (yishaib)" <[email-masked]>
Date: Tue, 12 Mar 2019 20:30:03 +0000

On 12/03/2019, 20:37, "Doh on behalf of Stephane Bortzmeyer" <[email-masked] on behalf of [email-masked]> wrote:

    
    
It is common practice for Malware operators to use bona fide DNS infrastructure (including resolvers) to communicate with the malware application. One useful example are DGAs [1]. This practice is cheaper and more robust for Malware operators than setting up their own DNS resolver service, not to mention implementing a proprietary protocol. It also helps isolate the malware operator from the malware as these communications all happen through legit services (all the malware operator has to do to trigger the resident malware is to register a domain).

DoH, and specifically the (intended) inability to distinguish DoH from other traffic, makes this practice much harder to detect and to block - which is why this a problem that did not already exist before.

[1] https://umbrella.cisco.com/blog/2016/10/10/domain-generation-algorithms-effective/

Yishai

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Mar 2019 13:31:54 -0700

On 3/12/2019 12:56 PM, Paul Vixie wrote:
> i don't like the chinese government's rules for the great firewall. so, i keep 
> my visits to that otherwise-great country short. this hurts me, and maybe 
> hurts them also. but, it's their country, and i will obey their laws when i am 
> using their network. and then i'll vote with my feet, to get to a better 
> network with better rules. i once traveled to HK for a weekend between two 
> week-long conferences behind the GFW, just so i could get work done.

There is a lot of difference between what can be imposed in a police
state and what looks legitimate in a user agreement in a free country.
And I sure hope that we maintain that difference. A good result of that
discussion would be to clarify these differences. For example, there are
legal differences between what can be done in a private home, and what
can be done in a place like a hotel that provides public accommodation.
Just like hotels cannot discriminate against some categories of
customers, I don't think that places providing public connectivity
should be able to discriminate against content accessed by their guests.

-- Christian Huitema

---

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

...
> > i don't like the chinese government's rules for the great firewall. so, i
> > keep my visits to that otherwise-great country short. this hurts me, and
> > maybe hurts them also. but, it's their country, and i will obey their
> > laws when i am using their network. and then i'll vote with my feet, to
> > get to a better network with better rules. i once traveled to HK for a
> > weekend between two week-long conferences behind the GFW, just so i could
> > get work done.

> And I sure hope that we maintain that difference.

i expect you to be disappointed in that hope, if you work on this long enough.

> A good result of that

there are also legal differences from nation to nation, from state to state, 
from county to county, and from city to city. the internet is below all of 
that.

> should be able to discriminate against content accessed by their guests.

just as i've cautioned the RFC 8484 authors against imposing their anti-
censorship views on my parental controls or corporate network policies, let me 
here caution you against imposing your (clearly) western liberal-democratic 
views on the development of protocols whose ideal state is "interoperability" 
and never more or less.

vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Mar 2019 19:56:30 +0000

On Tuesday, 12 March 2019 18:56:05 UTC Christian Huitema wrote:
> Paul, who is this someone?

a network operator.

> How do they decide? What does dangerous mean?

that's a local policy matter, not subject to standardization, thus off-topic 
here.

> answers are not as black and white as "this is my network, I get to decide".

if it is my network, i get to decide. that's what i told spammers when i 
started the first anti-spam company (MAPS) and co-invented the first 
distributed reputation protocol (RBL), 23 years ago. it remains true today.

my network, my rules. don't like my rules? use a different network.

> is entitled to override the user choices and impose their own. Really?

no. not really. not at all. because, as before, you are claiming to restate my 
position, but doing so erroneously.

if you visit my home or office, you will either use my offered RDNS, or you 
will use an authorized VPN. so, beware. those are the rules. if you want 
different rules, use a different network.

vixie

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2019 21:05:36 +0000

Paul,

> views on the development of protocols whose ideal state is "interoperability" 

I'm sorry but I don't understand this argument.

DoH interoperates pretty well.

You and Christian have expressed different concerns not
related to interop.

I don't see why, based on your argument, your concerns
trump his.

Can you explain?

Thanks,
S.

---

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

On Tuesday, 12 March 2019 21:05:36 UTC Stephen Farrell wrote:
> > censorship views on my parental controls or corporate network policies,
> > let me here caution you against imposing your (clearly) western
> > liberal-democratic views on the development of protocols whose ideal
> > state is "interoperability" and never more or less.
> 

but does it intend more, or less?

>    interfering with DNS operations, ...

(from Introduction, RFC 8484.)

> You and Christian have expressed different concerns not

did you read what i wrote?

> I don't see why, based on your argument, your concerns

he's trying to achieve a political aim using technology. that is not the 
purpose for which the internet engineering task force, or the internet itself, 
was convened. it is not why our employers pay our travel costs. and it is not 
why the rest of the world trusts our outputs.

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 12 Mar 2019 21:38:44 +0000

On 12/03/2019 21:11, Paul Vixie wrote:
> he's trying to achieve a political aim using technology.

Ok, now I think I understand and am pretty sure I disagree
with you there.

There are reasons to want confidentiality for DNS queries
and answers, and access patterns, for which the IETF has
achieved consensus. (See RFC7626) (*)

DoT is one way to tackle those problems. DoH is another.
I think an argument that DoH is "just politics" and is
not aiming to try provided a security/privacy mechanism to
tackle a problem on which the IETF has consensus falls on
that basis myself.

I fully agree that there are potential DoH deployments
that could have side-effects (more that DoT) that warrant
more discussion, but I figure your arguments along the
above lines are misdirected.

Cheers,
S.

(*) Ironically, one of the arguments against DoH raised
in this discussion is that it would expose that kind of
information from split-horizon deployments, so it seems
that even those concerned about DoH accept the problem
statement, which is helpful.

---

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

> achieved consensus. (See RFC7626) (*)

i have no qualms about confidentiality, for traffic allowed by a network 
operator. it's the inability to interefere (as called for in RFC 8484) and not 
the inability to observe (as called for in RFC 7626) that's at issue here.

> DoT is one way to tackle those problems. DoH is another.

DoT does not intend to place itself beyond interference by on-path entities, 
and as such, my choice as a network operator is either to allow it through 
even though i can't see the contents, or disallow it. and that's all fine.

DoH intends "to prevent on-path interference with DNS operations", and that's 
well beyond the remit of RFC 7626, and is therefore not spoken to one way or 
another by IETF consensus. i do not believe that a non-interference objective 
would reach broader IETF consensus. perhaps we can test that one day.

vixie

---

From: Brian Dickson <[email-masked]>
Date: Tue, 12 Mar 2019 16:12:37 -0700

> even though i can't see the contents, or disallow it. and that's all fine.
I think there is a way to use technical design(s) to split hairs, i.e. I
think the side meeting
has the possibility of bearing fruit which is palatable enough for all
parties.

The crux of the problem is how to determine if the network operator is
truly hostile (GFC),
or merely restrictive (Paul's network, Paul's rules.)

Suppose the client signaled a desire to use a particular DoH operator.
The network could respond with, "No", or "Yes", or "Yes, but I want to
inspect your DNS traffic",
or "No, but I'll place you logically outside my network, and enable the
isolated bubble you are in to do what you want."
The client could treat "No" as hostile, and do something appropriate for
being behind the GFC.
The client could treat the "Yes, but" as a reason to then ask for the
"bubble" treatment.
If the client is offered and accepts, or requests and is permitted, the
"bubble" treatment, there is no need to go hostile.
In "bubble", the client would not be able to interact with any local
resources, in effect being in a non-split-mode VPN to the outside world.

There is really nothing that would stop a non-compliant client (or malware)
from choosing the "hostile" mode.
However, if "bubble" is available, I don't see why that would not be
acceptable for any client that isn't malicious.

Does "bubble" (and the signaling required) seem like a promising compromise?
(Presuming the operator can still refuse "bubble" requests, of course,
perhaps with a polite message denying the request with an explanation.)

(Also, I would expect the MDM thing can be reduced to whether client(s) are
allowed to go hostile or do "bubble" mode.)

Brian

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Mar 2019 00:36:32 +0000

Hiya,

On 12/03/2019 22:51, Paul Vixie wrote:
> operator. 

To me, the above reads as self-contradictory. If the traffic is
confidential the operator doesn't know if its "allowed" except
possibly in some extremely coarse-grained sense. Perhaps when
you said "traffic allowed" maybe you meant "protocol allowed"?
But even that is confusing, given the likes of websockets, alpn,
and other webby ways in which stuff gets layered on 443 all
the time.

> it's the inability to interefere (as called for in RFC 8484) and not 

Hmm. Not sure what to make of that. DNSSEC presumably makes it
possible to detect interference, and yet RPZ (IIRC) calls for
not changing DNSSEC-signed answers. I don't get why an inability
to change is ok for the RPZ/DNSSEC context but not for DoH.

Another possibility is that we're discovering that when this
confidentiality stuff gets used for real, we find that we'd
really prefer to not have to change what we've been doing before.
I don't mean that as an accusation but it has been easy to
ignore e.g. the lack of deployment of DNSSEC or more recently,
DoT.

> would reach broader IETF consensus. perhaps we can test that one day.

Over the years, we've had quite a few people propose schemes to
provide integrity (and presumably hence prevent "interference")
but no confidentiality. (There's an ongoing discussion of the very
latest iteration of that on the TLS list in the last month or so.)
That leads me to guess that a position that "interference is ok
but confidentiality is not a problem" is not one that'd tend to
garner consensus. But as you say, maybe some day we'll test that
proposition.

Cheers,
S.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 13 Mar 2019 12:04:21 +1100

> On 13 Mar 2019, at 3:02 am, Jim Reid <[email-masked]> wrote:
> 
> 
> 

And what part of doing a DNS lookups breaks any reasonable terms and conditions?

> [email-masked]

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

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Mar 2019 21:04:27 -0400 (EDT)

> to change is ok for the RPZ/DNSSEC context but not for DoH.

no. RPZ allows filtering answers which would turn into BOGUS for
DNSSEC validating clients. I am waiting for RPZ to be an RFC to
start a bis document that moves the Answer to the Authoritative
section, so you can indeed detect the network's desire for protecting
you, and use DNSSEC to confirm you are not censored without consent.

Paul
ps. I owe the ISE a rpz document review, so it is partially my fault
this is stuck now. I hope to get enough airplane time in the next two
weeks to fix that :)

---

From: Paul Wouters <[email-masked]>
Date: Tue, 12 Mar 2019 21:10:37 -0400 (EDT)

On Tue, 12 Mar 2019, Paul Vixie wrote:

> network with better rules.

This is spoken from priviledge and really pretty unfair to claim.

If tomorrow Trump installed mandated ISP DNS firewalls with RPZ that
every MUST use and is a crime to not use, and fbi.gov is filtered like
tiananmen square you would not follow your governments rules because it
is their/your country, nor denaturalize yourself and move country.

I remember all the people who would leave California if Arnold would
become governor. Or when Bush would be elected. Twice. And those who
would leave when Trump would be elected. I know of exactly 0 individuals
who kept their promise.

Paul

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Mar 2019 01:16:13 +0000

Hiya,

On 13/03/2019 01:04, Paul Wouters wrote:
> RPZ allows filtering answers which would turn into BOGUS for
> DNSSEC validating clients.

Could well be my terminology was imprecise. What I recalled
from some discussion a year or more ago was that RPZ MUST NOT
change a DNSSEC-signed answer that verifies.

If that's wrong or no longer the case then my point there is
off base. (I'll go back and find another tomorrow:-)

If I'm correct, then I remain puzzled as to why Paul V. finds
it acceptable to be unable to "interfere" with DNS answers in
one case (RPZ-with-good-DNSSEC) but not the other (DoH).

Cheers,
S.

---

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

> would reach broader IETF consensus. perhaps we can test that one day.

I'm not sure I understand the double-double negative happening here.

It appears to me that there is considerable support for DoH, meaning 
there is support for non-interference.

In the IPv6 spectrum with the mac/slaac randomization games which have 
become standardized, and which have been instituted to supply other 
forms of security/hiding/non-interference, it appears that DoH would 
similarly be 'allowed' through the standardization process.

Having said that, and if this is how one performs the testing, I would 
have to say that DoH would be make it much harder for me as a security 
engineer to perform my duties.

It would seem that if DoH is standardized, then it would probably become 
standard practice, then like 8.8.8.8 and similar quads, by default 
meaningful data becomes hidden for managing the interior of networks.

For some networks, pi-hole is a mechanism for preventing certain traffic 
operations.  AS I look at it this moment, it has over 112K domains 
blacklisted, and on one particular network, 31% of the queries have been 
blocked as a passive protection mechanism.

I find these blocks useful.  With DoH, probably DoH would become 
ubiquitous, and these types of blocks would be prevented.

Https is common ground for much hiding.  DNS is probably our last 
bastion of having any semblance of identification of what is happneing 
to the interior of our networks.  Carriers might not be so concerned. 
But for those who operation enterprise, business, home, some forms of 
social protection, security management becomes more difficult.

As has happened in the IPv6 space, the same happens here in the DNS 
space: there are groups who wish the privacy/non-interference/hiding 
ability vs the groups who need the information in the data streams to 
properly secure and manage the interior and perimeter.

How would the requirements of each group be recognized?  The simplest 
would be to not proceed with DoH.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 13 Mar 2019 03:30:14 +0100 (CET)

> Il 13 marzo 2019 alle 3.20 Raymond Burkholder <[email-masked]> ha scritto:
> 

I think there is support within the IETF, but "non-interference" on DNS has lots of implications at the legal, business, policy and political levels, which implies that there are many more stakeholders than the technical community, and these stakeholders have never been asked what they think of this. This is part of the discussion that needs to happen to get to broad consensus on DoH deployment models, as opposed to a technical arms race to enable/stop DoH between the Web people on one side and the security, ISP and government people on the other.

> would be to not proceed with DoH.

My draft attempts exactly to promote a discussion to find the conditions (if any exist) under which DoH could be deployed  broadly without making any stakeholder group [too] unhappy.

Regards,
-- 

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

---

From: nalini elkins <[email-masked]>
Date: Wed, 13 Mar 2019 08:02:19 +0530

Paul,

On Wed, Mar 13, 2019 at 1:03 AM Paul Vixie <[email-masked]> wrote:

> something
Thank you.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 13 Mar 2019 03:56:58 +0100 (CET)

> Il 12 marzo 2019 alle 19.56 Christian Huitema <[email-masked]> ha scritto:
> 
> what sites I could or could not access.

The reaction I got from some policy people when I mentioned this kind of arguments going on here is "when did the IETF get the mandate to decide for everyone that content filtering by intermediaries is always bad? This is matter for competition / telco / human rights legislation, and will vary country by country."

To quote what you wrote in another message:

> There is a lot of difference between what can be imposed in a 
> police state and what looks legitimate in a user agreement in a 
> free country. And I sure hope that we maintain that difference. A 
> good result of that discussion would be to clarify these 
> differences.

Do you really think that this is the IETF's job? Deciding "what looks legitimate in a user agreement in a free country" (and presumably, also what tells "a police state" from "a free country") and enforcing such decision via technical measures?

Ciao,
--

---

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

On 2019-03-12 2:51 p.m., Paul Vixie wrote:
> ...  development of protocols whose ideal state is "interoperability"
> and never more or less.

slightly out of context, but I find the 'interoperability' context as an 
underlying definition worthy of support.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Mar 2019 20:39:42 -0700

> The reaction I got from some policy people when I mentioned this kind of arguments going on here is "when did the IETF get the mandate to decide for everyone that content filtering by intermediarie…

The mirror image of that statement is, "when did intermediaries get a
mandate to filter content?" The internet architecture assumes full
connectivity. At some point, people deployed middle-boxes and filtered
content because they could. They did not exactly try to get a mandate,
or obtain consensus that this was proper. Technologies like DoH force
the discussion in the open. Why do you think you can filter content? Who
made you king?

-- Christian Huitema

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 13 Mar 2019 05:25:24 +0100 (CET)

> Il 13 marzo 2019 alle 4.39 Christian Huitema <[email-masked]> ha scritto:
> 
> mandate to filter content?"

When a regularly elected government, having sovereignty over them and their users, told them that they can / should / must do it.

Note that I don't particularly like this practice (I'm currently busy in the battle against Article 13 in the EU), I'm just trying to sort out everyone's role in this discussion. 

Regards,
--

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Mar 2019 19:59:07 -0700

> why the rest of the world trusts our outputs.

Sorry, but no. I am vying for network transparency, and I believe that
if filtering is to be enforced, it should be controlled by the user. You
are claiming that safety mandates giving the network operator full
control over name resolution. Both of these positions come from specific
visions about how the network should work. Neither is more a political
goal than the other.

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Tue, 12 Mar 2019 21:38:06 -0700

> Note that I don't particularly like this practice (I'm currently busy in the battle against Article 13 in the EU), I'm just trying to sort out everyone's role in this discussion. 

The legal mandate is really a best effort mandate, as in "if you provide
name resolution, you should not resolve name X, Y and Z". It is a
constraint on the way a service provider provides a specific service. It
is not a grant of monopoly, that only the connectivity provider should
provide name resolution. It could perhaps be interpreted to say that DoH
providers, subject to the same laws as ISP, should perform the same
filtering. But that's a different question.

-- Christian Huitema

---

From: Eliot Lear <[email-masked]>
Date: Wed, 13 Mar 2019 06:04:17 +0100

Gentlemen,

This conversation has gone to the zoo.  What is or is not political doesn’t matter at this stage in the game, and neither is arguing over rights over bits.  If people want to do that I suggest doing so in the HRPC WG and with a draft in hand.  Flaming back and forth without an objective of actually modifying text or developing a work proposal is quite pointless.

What is important is to document the technical ramifications of the changes brought about by DoH.  To move things forward, can we simply go through the drafts in the side meeting, and indicate what administrators might do about any perceived negative effects?  Whether those effects seem negative to you only matters if there is a proposal for the IETF to take on new work to “correct” them.

Eliot

> On 13 Mar 2019, at 03:59, Christian Huitema <[email-masked]> wrote:
> 
> 
> 
> Sorry, but no. I am vying for network transparency, and I believe that if filtering is to be enforced, it should be controlled by the user. You are claiming that safety mandates giving the network operator full control over name resolution. Both of these positions come from specific visions about how the network should work. Neither is more a political goal than the other.
> 
> -- Christian Huitema
>

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 13 Mar 2019 05:37:26 +0000

Please see inline

From: Eric Rescorla <[email-masked]>
Sent: Tuesday, March 12, 2019 9:28 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: [email-masked]; [email-masked]; [email-masked]; Vittorio Bertola <vittorio.bertola=[email-masked]>; Stephen Farrell <[email-masked]>
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

On Tue, Mar 12, 2019 at 8:51 AM Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

In ordinary TLS 1.3, the SNI is in the clear but the server cert is not. However, importantly, even in TLS 1.2, the server certificate is not verifiable, and therefore is not significantly more trustworthy than SNI.

[TR] Middle boxes have a trust store (e.g. downloaded from Mozilla CA store) to validate the server certificate.  Malwares lie about SNI (typically use a FQDN whose reputation score is good), validating the server certificate (e.g. certain types of malwares  use self-signed certificates) and SNI mismatch helps detect the client is lying.

With ESNI, the SNI is encrypted (hence the name). However, the xpectation is that enterprises which want to do conditional inspection will disable ESNI on the client. This should not be problematic as they already need access to the client to install their own trust anchor.

[TR] I see Firefox has given an option to disable ESNI, hopefully others will provide a configurable option.

Cheers,
-Tiru

-Ekr

-Tiru

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Sent: Tuesday, March 12, 2019 3:14 AM
To: Paul Vixie <[email-masked]<mailto:[email-masked]>>
Cc: nalini elkins <[email-masked]<mailto:[email-masked]>>; Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ackermann, Michael <[email-masked]<mailto:[email-masked]>>; Christian Huitema <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>; Vittorio Bertola <vittorio.bertola=[email-masked]<mailto:[email-masked]>>; Stephen Farrell <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Doh] [dns-privacy] [DNSOP] New: draft-bertola-bcp-doh-clients

-Ekr

--
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Mar 2019 06:28:23 +0000

> has the possibility of bearing fruit which is palatable enough for all

i hope so. i will only be in prague from saturday evening 'til monday morning.

> or merely restrictive (Paul's network, Paul's rules.)

no, that's not the crux. it's only one problem, the one being had by a user or 
application wondering which dns server and what protocol to use.

there's another problem, considered the crux by some, but still only one 
problem, and that's how to prevent truly hostile users or apps from bypassing 
the security policy implemented in the local RDNS control plane.

neither one gets to call itself the crux, i think.

vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Mar 2019 06:45:42 +0000

...
> you said "traffic allowed" maybe you meant "protocol allowed"?

yes.

> and other webby ways in which stuff gets layered on 443 all

relevant security mechanisms allow for short term losses, leading to long term 
policy shifts. that is, i didn't isolate my chromecast-ultra until it 
misbehaved too egregiously. at work we're on more of a hair trigger.

> > it's the inability to inter[e]fere (as called for in RFC 8484) and not

i think that's off-topic. my point is, as an operator, i can decide whether to 
allow DoT to off-net providers, based on whether it's OK with me that i cannot 
see what it's doing OR interfere with its results. (and i choose _not to_.) 
whereas, as an operator, that choice was deliberately taken out of my hands 
with respect to DoH... by design.

i think if the DoH people had wanted operators to have a choice, they might 
have said, DoT will handle anti-surveillance and anti-interference if it 
works, and the runtime will handle the selection. and, they wouldn't have said 
that one of their goals was to prevent on-path interference in DNS operations.

their def'n of "interfere" is probably unrelated, having a totally different 
scope, to the RPZ concept of interference.

> ignore e.g. the lack of deployment of DNSSEC or more recently,

i don't take it as an accusation, but this is about security economics, not 
new vs. old ways of doing the same thing, or preferences. the DoH people 
intended to dramatically raise the costs of on-path DNS interference. as an 
on-path interference fan, i don't like the choices they've left me with. one 
of those is "let any user or app inside my network do its DNS outside of my 
surveillance and outside of my (RPZ) policy controls." i won't be choosing 
that. my motives are grounded in security economics, teenagers, and malware.

vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Mar 2019 07:48:42 +0000

On Wednesday, 13 March 2019 02:59:07 UTC Christian Huitema wrote:
> > purpose for which the internet engineering task force, or the internet
> > itself, was convened. it is not why our employers pay our travel costs.
> > and it is not why the rest of the world trusts our outputs.
> 
> Sorry, but no. I am vying for network transparency, ...

sir, that is a political position.

> and I believe that
> if filtering is to be enforced, it should be controlled by the user.

sir, that is a political position.

> You
> control over name resolution. ...

i am speaking not of the platonic perfect form of safety, of which any 
particular kind of safety is a mere imperfect reflection, but rather of a 
*very* particular kind of safety, that of the networks i operate. it is for 
me, and me alone, which is to say not for you, to say what kind of safety my 
network needs, or should have, or will have.

> Both of these positions come from specific

your stated goals are entirely political, resting in no way on economics, 
psychology, science, metaphysics, epistemology, or even engineering.

vixie

---

From: Brian Haberman <[email-masked]>
Date: Wed, 13 Mar 2019 08:48:21 -0400

All,
     I am saying this with my dprive WG chair hat on...

     As Eliot points out, this conversation has deteriorated beyond
repair. I will now politely ask that these non-technical discussions
cease on the dprive mailing list. I would recommend that everyone
document their concerns with DoH and bring them to the side meeting
being proposed by Stephane.

Regards,
Brian

---

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

In the below commentary, there are some use cases which are not being 
included ....
> answers are not as black and white as "this is my network, I get to decide".

There are enterprise networks.  There are home networks. There are some 
socially organized networks.  All seeking protection for their users, or 
for themselves, or both.  And sometimes/many-times, there has to be 
'some-one' who can define some level of protection for the collection of 
users.

DoH is almost like a trojan.  Secret queries can be made to the outside 
world. For the 'protector' of the infrastructure, the job then becomes 
more difficult to perform.

Are there security personnel included in these conversations?

> is a market for these products, they compete based on reputation, ease

This could be a legitimate scenario.  But what if users are inside the 
domain of enterprise/home/organization/social, they would need to 
delegate their security to those who are maintaining that 'network'. 
But when the users can build their own DoH 'tunnels' and hide that 
traffic amongst other https traffic, security can be harder to 
enforce/manage/supervise/maintain/forensically-identify.

> is entitled to override the user choices and impose their own. Really?

I would say, yes.

> what sites I could or could not access. It really is a tussle.

Yes, a tussle.  There are many use cases.

The 'power of the individual' vs the 'will of the people'?   [does not 
totally properly convey the concept, but close enough]

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 13 Mar 2019 16:56:32 +0000

On 3/12/19, 11:40 PM, "Doh on behalf of Christian Huitema" <[email-masked] on behalf of [email-masked]> wrote:

> Why do you think you can filter content? Who made you king?

[JL] End users may have opted into / subscribed to such a parental control system. An enterprise may say we'll only connect to the Internet and allow traffic of X or Y type in/out for security reasons. And a primary school may be legally required to filter out adult content in exchange for a government grant to fund their network/computers/connectivity. There are many more examples that can be considered.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Mar 2019 13:29:28 -0700

On Wed, Mar 13, 2019 at 12:18 PM Christian Huitema <[email-masked]>
wrote:

>  But then, if the user has not opted in such system, it would be nice if
> the ISP refrained from interfering with name resolution for that user. How
> do we achieve those two goals in practice?
>
> -- Christian Huitema
>
Even that starting point is not accurate or correct, IMHO, at least for
scope, or whether/how any given DoH implementation interacts with the
user(s).

Jason was suggesting that there are (or at least may be) multiple levels of
ISP and/or Enterprise and/or controlled (parental) stuff; those might nest
with no "naked" root (unfiltered) depending on the particular ISP, or
mandated legal thing, or "public" offering doing anything questionable.

Notwithstanding any desire to have users use DoH to arbitrary endpoints, in
some environments (enterprises) or regulatory environments (western
countries which have different restrictions on legal contracts and user
acceptance stuff.

This means that it is NOT the case that EVERY potential deployment
environment is going to be compatible with a DoH client that bypasses any
controls that might be present, without violating laws, contracts, or other
controlling limitations.

The starting place for the conversation needs to acknowledge this, and
accommodate it. It is entirely possible that a DoH client that doesn't do a
minimum level of getting user acknowledgement before violating policies,
laws, or contracts, might itself be illegal in some jurisdictions
(jurisdictions that could include some US states, some western countries,
some larger entities like EU, etc.).

This is not to say it isn't going to be the case that users can't "force"
some kind of DoH-like thing, only that it needs to be under some kind of
affirmative control, where a user makes an informed decision with some kind
of explicit understanding/acknowledgement.

It probably would be advisable for DoH implementations to NOT make that
explicit acknowledgement externally visible to e.g. authoritarian regimes,
but that is stuff to discuss/explore, i.e. it's an open question.

It would be very helpful for moving the conversation forward if the DoH
proponents could start with acknowledging this set of legal/contractual
issues, and that any kind of DoH client that just automatically does stuff
that bypasses any mechanisms to restrict DNS, likely isn't known to be
compliant with all laws in all jurisdiction (and probably would be
problematic, at a minimum).

Brian

---

From: Christian Huitema <[email-masked]>
Date: Wed, 13 Mar 2019 12:18:17 -0700

> [JL] End users may have opted into / subscribed to such a parental control system. An enterprise may say we'll only connect to the Internet and allow traffic of X or Y type in/out for security reas…

Take the example of end users who may have opted in a parental control
system. Some may have, and some may not have. If we want a productive
conversation, we need to start from scenarios like that. If an end user
has opted in a specific parental control system, then applications
performing their own name resolution should follow the end user
preference, and it would be nice to have a management interface exposing
that. But then, if the user has not opted in such system, it would be
nice if the ISP refrained from interfering with name resolution for that
user. How do we achieve those two goals in practice?

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Mar 2019 20:43:21 +0000

(dropping dprive list at WG chair request)

Hiya,

> some larger entities like EU, etc.).

I almost agreed with you that people need to ack others'
priorities. But the above means I can't agree with your
mail as "might be illegal" is vastly overstated, there
being no relevant difference between DoT and DoH clients
in this respect. Such overstatement doesn't help and merely
makes it more likely that some of the reasonable points
you make will just get lost in the noise (IMO anyway).

The same goes for talk of "wars" btw.

Cheers,
S.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 13 Mar 2019 14:06:13 -0700

On Wed, Mar 13, 2019 at 1:43 PM Stephen Farrell <[email-masked]>
wrote:

> in this respect.

You are correct, on the difference issue.

This is about the base requirements, even if they are not different between
DoH and DoT.
And I agree, both DoH and DoT would need to meet the same set of
requirements wrt to contracts, laws, informed users, and everything.

I don't believe I am overstating the issue, at least in some places.
E.g. I am not aware of any place where an end user can modify an EULA, sign
it, and have that legally binding. Doing DoH/DoT in any such environment
where the Ts & Cs prohibit their use, would at least be a contract
violation. Things like DMCA and its ilk might raise the software to the
level of "illegal" rather than just a contract violation by a user.

> Such overstatement doesn't help and merely
> Yeah, that's not one term I have used, but I agree.

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 13 Mar 2019 21:17:05 +0000

On 13/03/2019 21:06, Brian Dickson wrote:
> Things like DMCA and its ilk might raise the software to the

Whacking someone in the head with a fish could well be
illegal... but fish are not illegal:-) [1]

Similarly typing "dig <blasphemous-word>.example" may
be argued to cause some theoretical illegality in some
locations but neither the DNS protocol nor service is
illegal as a result.

And IANAL.

But it's ok that we disagree that this is overblown,
except for the way in which it makes the conversation
needlessly harder.

Cheers,
S.

[1] https://en.wikipedia.org/wiki/The_Fish-Slapping_Dance

---

From: Michael Sinatra <[email-masked]>
Date: Wed, 13 Mar 2019 17:07:24 -0700

> being no relevant difference between DoT and DoH clients

I believe that the issue of protocol obfuscation that I mentioned
earlier in the draft-reid-doh-operator thread[1] is a relevant difference.

There is another technical issue, and that surrounds the question of who
is the user and what capabilities does the user have to manage their
devices.  This has been touched upon with the discussion on opt-in vs.
default and with Paul's discussion of data exfiltration.

In my home, I have an "Internet-capable" washing machine.  Of course my
"smart" TV wants to be on the Internet.  My Foobot *must* be on the
Internet just so I can monitor the air quality in my own home.  I don't
want the washer on the Internet at all, and for some of the other
devices, I want to control what they do on my home network.  With
embedded and "IoT" devices, there may be limitations on how I--as the
user--can control them.  There may be hard-coded defaults that are
difficult to change (and yet have a way of easily resetting themselves
to "factory default").  Leaving aside for now the issue of licensing
Ts&Cs, I--as the user--may want to have more *technical* control over
the devices than their vendor is willing to give me.  One way I can
assert that control is via the network.  On my home network, I am one of
the users and I am also the network admin.  I want to assert control
over the devices for which *I* am the user, but the people who designed
them didn't give them sufficient knobs for me to do this on the device.

Another word for software which does things on the network outside of
the user's control is "malware," whether it is legitimate or not, and I
realize it predates DoH.  But DoH legitimizes protocol obfuscation at
the network layer and makes it potentially harder for me to control the
devices for which I am the user.  So if the goal is to give users more
control, I'd assert that DoH, at best, works both ways.

michael

[1] https://mailarchive.ietf.org/arch/msg/dnsop/Qole4yY0q_-psyrvWabaRAD8_Vc

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 14 Mar 2019 01:17:52 +0000

Hi,

> earlier in the draft-reid-doh-operator thread[1] is a relevant difference.

I do not believe that is relevant to the claim I was disputing
which was essentially that somehow DoH "might be illegal."

If you think your point above is relevant, please consider Tor,
whose major funder is (or historically was) a government and
which is not illegal as far as I know (in many places). And VPNs
too (but only the good ones:-).

> control, I'd assert that DoH, at best, works both ways.
Those seem like unrelated (and repetitive) points, except for your
attempt to try equate (I assume) a browser using DoH with malware.
That's the kind of overblown statement that detracts from any other
reasonable points you may make (for me at least).

I do agree that knowledgeable network owners, especially home network
owners, ought be able to exercise control over the networks they own.
I'm perfectly fine to do that in my home network and have no fear of
DoH at all - I'm well used to turning off, working around or living
with what I consider crappy features of browsers (e.g. cookies, JS)
and other tech artefacts. DoH at least has some upsides if it gets
implemented properly.

I don't personally know how to properly and fairly handle such issues
for network owners who quite reasonably don't know anything about the
tech. ISTM that (to date) we've all contributed to failing such network
owners. DoH is nothing special in that respect, nor is RPZ and nor are
many other technologies we've developed.

From my POV, the only thing I hear about DoH that's new(-ish) is a fear
that browsers will turn it on by default in a silly manner, with some
negative but not world-shattering consequences for folks who have a
quite reasonable interest in existing DNS-based technologies and
services.

(Well, that and I've a continuing concern that somehow DoH might end
up enabling web-severs succeed at drive-by attacks on client DNS
caches if someone does some really stupid implementation stuff. But
everyone keeps telling me that'll be ok;-)

Cheers,
S.

---

From: Adam Roach <[email-masked]>
Date: Wed, 13 Mar 2019 21:47:24 -0500

> locations but neither the DNS protocol nor service is

Closer to home, VoIP was illegal in a double-digit number of countries 
when the IETF started work on SIP.

/a

---

From: Michael Sinatra <[email-masked]>
Date: Thu, 14 Mar 2019 09:18:12 -0700

On 3/13/19 6:17 PM, Stephen Farrell wrote:

> attempt to try equate (I assume) a browser using DoH with malware.> That's the kind of overblown statement that detracts from any other

No, that's not quite it.  My point is that lots of people who support
DoH say that this cat is already out of the bag.  My point is to agree
with Paul and Jim and others who have noted that it's a matter of scale
and legitimization as a proposed standard that *differentiates* DoH from
malware.

Apologies if my previous post was too wordy or repetitive, so I'll just
sum it up: I question the assumption, made in these threads, that DoH
affords users more control.

thanks,
michael