Subject: [Doh] Fallback to untrusted DOH servers

From: Mateusz Jończyk <[email-masked]>
Date: Sat, 14 Apr 2018 18:36:58 +0200

Hello,
Current DOH draft specifies that:

   A client MUST
   NOT trust a DNS API server simply because it was discovered, or
   because the client was told to trust the DNS API server by an
   untrusted party.  Instead, a client MUST only trust DNS API server
   that is configured as trustworthy.

It may happen that either no trustworthy DOH server has been configured, or the
configured DOH server is not working. In such cases a DOH client would usually
revert to using an untrusted DNS server on port 53, possibly one that was
discovered through unsecure DHCP. This DNS resolver would also be able to poison
DNS caches then.

I think that in this case it would be better to use whatever DOH server is
available as an alternative to an even worse old-school DNS. To avoid cache
poisoning attacks, the client would then have to drop DNS caches after switching
to a more trustworthy DNS once it has been configured or is available.

Also, the current draft does not specify any way of querying IP addresses of
hosts on the local network - it is assumed that if a DNS API server would return
NXDOMAIN the client would query the local old-school DNS server whether the
hostname translates to an IP address on a local network. In the future, there
may be specified a discovery mechanism for a local fallback DOH server, for
example by a DHCP option.

A client would have to drop DNS caches when switching networks anyway to avoid
any stale entries related to local hosts.

Therefore, I would propose the following text:

   A client SHOULD
   NOT trust a DNS API server simply because it was discovered, or
   because the client was told to trust the DNS API server by an
   untrusted party.  Instead, a client SHOULD only trust a DNS API server
   that is configured as trustworthy. A client MAY use an untrustworthy
   DNS API server as a fallback, for example: when no trustworthy DNS API
   server is configured, no configured DNS server works or
   when the trustworthy DNS API server returned NXDOMAIN (and checking whether
   the hostname is a local domain).

   The client MUST drop DNS caches when switching from an untrustworthy
   DNS API server to a trustworthy one.

It should be also noted that the client should drop DNS caches when switching
from an unsecure DNS to DOH.

   "A client SHOULD drop DNS caches when switching from less secure DNS
   retrieval mechanisms to DOH."

Greetings,
Mateusz Jończyk

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Apr 2018 10:34:31 -0700

> to a more trustworthy DNS once it has been configured or is available.

What threat model do you want to address?   Two things spring to mind as things you might care about:
"do I trust the DNS server"
"is the connection to the DNS server private?"

If the resolver was configured with keying information that can be validated as part of making the connection to the server, then you trust the server.   What exactly that means is a question in itself, but let's take that for granted for now.

In the case of DOH-I-don't-know versus DNS-I-don't-know, you don't have (1), so it doesn't matter which one you use, except that if you use some method other than DHCP to get to the DOH server, potentially what you have reached is even _less_ trustworthy than the DNS server.   So you could as easily be worse off as better off.

What you do get with DOH-I-don't-know as compared to DNS-I-don't-know is (2), for some value of "private."

So what threats does preferring DOH protect you from?   What threats _doesn't_ it protect you from?   What vulnerabilities does it create?   I think you need to answer all three of these questions if you're going to make the case that untrusted DOH should be preferred over untrusted DNS.

Your question about the local resolver is interesting.   I think what it points to, though, is that what DOH does is to solve a very different problem than the problem you are trying to solve with it.

If you want to solve the problem you are proposing to solve, the place it needs to be solved is in the local stub resolver implementation.   This is something we've seen before, and there's even an RFC that talks about it, RFC7556.   From the perspective of RFC7556, your "trusted" DOH resolver represents a provisioning domain, and it's the domain in which you would prefer to look up names.   Your local DNS resolver represents another provisioning domain.   

Provisioning domain DNS caches must be separate, to avoid cache poisoning.   You might have a whitelist of domains that can be looked up using the local resolver, and all other domains are just not available if the trusted DOH server isn't present.   Or you could have a blacklist of domains that are only sent to the trusted DOH server, and other domains can go either way.   Or some other security policy.

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 14 Apr 2018 20:54:39 +0000

> discovered through unsecure DHCP. This DNS resolver would also be able to poison

The topic of how a user (well, really, an OS or browser) choose a DNS server to use is a worthy one to look at, but not in this document. If someone wants to start such a document, it needs to deal with trust in DHCP, DHCP MITMs, DNS-over-TLS, DNS-over-TLS policy, DOH, and DOH policy. (There are likely additional topics...)

--Paul Hoffman

---

From: Mateusz Jończyk <[email-masked]>
Date: Sun, 15 Apr 2018 19:19:06 +0200

W dniu 14.04.2018 o 19:34, Ted Lemon pisze:
> On Apr 14, 2018, at 9:36 AM, Mateusz Jończyk wrote:
>  1. "do I trust the DNS server"
>  2. "is the connection to the DNS server private?"
> 
> 
> If the resolver was configured with keying information that can be validated as
> part of making the connection to the server, then you trust the server.   What
> exactly that means is a question in itself, but let's take that for granted for now.
> 
> In the case of DOH-I-don't-know versus DNS-I-don't-know, you don't have (1), so
> it doesn't matter which one you use, except that if you use some method other
> than DHCP to get to the DOH server, potentially what you have reached is even
> _less_ trustworthy than the DNS server.   So you could as easily be worse off as
> better off.

I have been thinking exactly about discovering DOH servers via DHCP (in this or
a future RFC). I cannot think about any other sensible method of *discovering* a
DOH server (as opposed to using a preconfigured one).

A DOH server discovered via DHCP can be used for bootstrapping (a way of getting
the address of the trusted DOH resolver). For example, it may be used to query
the IP address of dns.google.com.

> for some value of "private."
Yup. Untrusted DOH protects the content of requests against everyone other then
the DOH server operator.

> So what threats does preferring DOH protect you from?   What threats _doesn't_
> it protect you from?   What vulnerabilities does it create?   I think you need
> to answer all three of these questions if you're going to make the case that
> untrusted DOH should be preferred over untrusted DNS.

> So what threats does preferring DOH protect you from?
Preferring DOH protects against passive network attacks (packet sniffing - as
opposed to active attacks). The NSA possibly monitors and stores DNS traffic.

> What threats _doesn't_ it protect you from?
Trying to phish the user is the most dangerous thing that I can imagine. An
attacker on the local network can run their own DOH server, try to spoof the
DHCP response, and then redirect the user to a phishing site.
But I would argue that an attacker on the local network can mount an ARP
spoofing attack and redirect all network traffic through themselves anyway and
then try to phish the user this way.

The untrusted DOH server can block some domains. It can also be used to monitor
which sites the user visits.

All of this is no worse then using untrusted old-school DNS.

Here, however, we are talking about a last-resort situation, and some kind of
fallback is neccessary - to untrusted DOH or untrusted DNS.

> What vulnerabilities does it create?
I would argue that no new (in comparison to old DNS), if properly implemented
(with separate caches).

On the other hand, why untrusted DNS should be preferred over untrusted DOH, as
the current draft implicitly specifies?

We may end up with the whole Internet using few DOH servers. There are probably
few providers that would host publicly-available DOH servers: Cloudflare
(1.1.1.1), Google, OpenDNS, IBM (or the folks responsible for 9.9.9.9) and
possibly Microsoft and Apple (for use with Windows / macOS) [3]. I doubt that
OpenDNS would be happy to have their DOH server configured in applications as
default, and Microsoft and Apple as well (in products other then theirs).

This would be very different from the current situation where most people are
using the DNS server of their own ISP (discovered via DHCP).

That change may be great because it increases privacy, but could create several
points of failure for the whole Internet [1]. It would be vulnerable to DoS or
some manipulation by the NSA. It is important to have some local fallback - i.e.
DOH or DNS servers hosted by ISPs.

> Your question about the local resolver is interesting.   I think what it points
> to, though, is that what DOH does is to solve a very different problem than the
> problem you are trying to solve with it.
> 
> If you want to solve the problem you are proposing to solve, the place it needs
> to be solved is in the local stub resolver implementation.   This is something
> we've seen before, and there's even an RFC that talks about it, RFC7556.   From
> the perspective of RFC7556, your "trusted" DOH resolver represents a
> provisioning domain, and it's the domain in which you would prefer to look up
> names.   Your local DNS resolver represents another provisioning domain.   
> 
I'm not sure that RFC7556 is exactly concerned with the problem we are talking
about.

> Provisioning domain DNS caches must be separate, to avoid cache poisoning.   
Yup, DNS caches would have to be separate. I have been talking about dropping
caches when switching providers, but having separate caches is much better.

> You> might have a whitelist of domains that can be looked up using the local
> resolver, and all other domains are just not available if the trusted DOH server
> isn't present.   Or you could have a blacklist of domains that are only sent to
> the trusted DOH server, and other domains can go either way.   Or some other
> security policy.
I have been talking about sensible defaults, not maintaining whitelists /
blacklists [2].

Currently, I suppose that most of the serious DOH resolvers work this way (or
will work this way): if the DOH query returns NXDOMAIN, they check the address
with a local resolver. This way they introduce (almost) no regressions when
resolving names.

This scheme is (I would argue) secure - when a global domain name is not used,
it does not hurt much if it resolves to something when querying the local
resolver. Thus I would argue that no whitelists / blacklists are necessary.

The current DOH draft forbids using a local, discovered DOH server for
resolution of local names.

Greetings,
Mateusz Jończyk

[1] This would be much worse then the current situation with DNS root servers.
[2] The whitelists / blacklists could be simple, though: for example most
Internet domain names end with a well-known country domain name, while most
local names do not have dots in the middle or are in the subdomain ".local" or
something similar.
[3] I'm skipping providers like ClearBrowsing and hobby sites incapable of
processing much traffic.

---

From: Mateusz Jończyk <[email-masked]>
Date: Sun, 15 Apr 2018 19:39:11 +0200

> The topic of how a user (well, really, an OS or browser) choose a DNS server to use is a worthy one to look at, but not in this document. If someone wants to start such a document, it needs to deal…

This draft specifies some limitations on DNS resolvers a client can use.
Therefore - I would argue - it is fine to discuss whether these limitations are
appropriate and not overbroad.

> --Paul Hoffman>

Greetings,
Mateusz Jończyk

---

From: Patrick McManus <[email-masked]>
Date: Sun, 15 Apr 2018 15:15:08 -0400

The document says "must not trust simply because it was discovered".. "only
trust configured".. and explicitly does not go into configuration.

imo you're reading too much into the text. It's just trying to say an
endpoint isn't to be trusted just because it speaks DoH and you found it
(e.g. becuase www.example.com pushed you a DoH request and response). Note
that it doesn't say "must not use" it says "must not trust". Whether or not
you would use an untrusted server if you have no trusted options is not
something that's going to be in scope here.

On Sun, Apr 15, 2018 at 1:39 PM, Mateusz Jończyk <[email-masked]> wrote:

> > The topic of how a user (well, really, an OS or browser) choose a DNS
> server to use is a worthy one to look at, but not in this document. If
> someone wants to start such a document, it needs to deal with trust in
> DHCP, DHCP MITMs, DNS-over-TLS, DNS-over-TLS policy, DOH, and DOH policy.
> (There are likely additional topics...)
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>
>

---

From: Mateusz Jończyk <[email-masked]>
Date: Sun, 22 Apr 2018 15:21:44 +0200

W dniu 15.04.2018 o 21:15, Patrick McManus pisze:
> imo you're reading too much into the text. It's just trying to say an endpoint
> isn't to be trusted just because it speaks DoH and you found it (e.g. becuase
> www.example.com <http://www.example.com> pushed you a DoH request and
> response). Note that it doesn't say "must not use" it says "must not trust".
> Whether or not you would use an untrusted server if you have no trusted
> options is not something that's going to be in scope here.
Hello,
Sorry, but I didn't have time to deal with DOH in the last week.

I think if Your interpretation of DOH is correct, that the text is unclear there
and should be clarified.
I would suggest to add the following clarification:

	A client MAY use an untrustworthy DNS API server as a fallback.

I am going to submit a draft that specifies how a fallback DNS API server could
be retrieved from DHCP.

Greetings,
Mateusz Jończyk

>
> On Sun, Apr 15, 2018 at 1:39 PM, Mateusz Jończyk <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     > On Apr 14, 2018, at 9:36 AM, Mateusz Jończyk <[email-masked] <mailto:[email-masked]>> wrote:
>     >>
>     >> Hello,
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/doh>
>
>

---

From: Paul Hoffman <[email-masked]>
Date: Sun, 22 Apr 2018 15:15:25 +0000

> 	A client MAY use an untrustworthy DNS API server as a fallback.

This seems horribly dangerous without a clear definition of "fallback".

> I am going to submit a draft that specifies how a fallback DNS API server could

That would be quite useful. If you do that, wouldn't it define the DNS API server as trusted?

--Paul Hoffman

---

From: Mateusz Jończyk <[email-masked]>
Date: Mon, 23 Apr 2018 11:36:46 +0200

> This seems horribly dangerous without a clear definition of "fallback".

There was a definition of "fallback" in a modification I proposed several mails
ago, but I removed it for sake of simplicity.

So, I would propose a following addition:
   A client MAY use an untrustworthy
   DNS API server as a fallback, for example: when no trustworthy DNS API
   server is configured, no configured DNS server works or
   when the trustworthy DNS API server returned NXDOMAIN (and the client
   checks whether an untrustworthy DNS API server would resolve the address in
   question).

   The client MUST use separate DNS API caches for trustworthy and untrustworthy
   DNS API servers or drop DNS caches when switching from an untrustworthy
   DNS API server to a trustworthy one.

Ted Lemon suggested in a private e-mail that contacting an untrusworthy DNS API
server after the trustworthy DNS API server returned NXDOMAIN exposes all
mistyped domains to the untrustworthy DNS API server. This is a valid concern,
and applies equally well to using old-school DNS in such a situation.

I would therefore propose to add the following warning after the phrase:
	"If a client of this protocol encounters an HTTP error after sending a
	DNS query, and then falls back to a different
	DNS retrieval mechanism, doing so can weaken the privacy and
	authenticity expected by the user of the client."

	When a DNS API server returns NXDOMAIN, a client may wish to check
	whether another server will resolve the domain name (as this may be
	a local name to be resolved by a local DNS server). Doing so will,
	however, expose all mistyped domain to that server.

> That would be quite useful. If you do that, wouldn't it define the DNS API server as trusted?

No, the server retrieved via DHCP is going to an untrustworthy DNS API server
(as defined above) as DHCP is usually unauthenticated and prone to various
manipulations.

Greetings,
Mateusz Jończyk

---

From: Patrick McManus <[email-masked]>
Date: Mon, 23 Apr 2018 12:40:48 +0000

I really think you are discussing discovery. The chairs have said that is
out of scope for this draft but they are soliciting proposals for new work
that could include it.

---

From: Mateusz Jończyk <[email-masked]>
Date: Mon, 23 Apr 2018 14:56:46 +0200

What I am discussing here are modifications to DOH so that adding support for
discovery would be possible without modifying the future RFC.

Thanks,
Mateusz Jończyk

W dniu 23.04.2018 o 14:40, Patrick McManus pisze:
> I really think you are discussing discovery. The chairs have said that is out of
> scope for this draft but they are soliciting proposals for new work that could
> include it.
> 
> On Mon, Apr 23, 2018, 06:04 Mateusz Jończyk <[email-masked]
>     > On Apr 22, 2018, at 6:21 AM, Mateusz Jończyk <[email-masked]

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Apr 2018 14:11:13 +0000

> discovery would be possible without modifying the future RFC.

Updating RFCs for reasons like this happens all the time in the IETF. Given that we don't know when such an update will happen (and I still believe it will take a long time to reconcile all of the DNS resolver discovery methods), it is better to leave the wording as-is and then update it when the complete document comes out.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Mon, 23 Apr 2018 10:42:24 -0400

Mateusz, I'm glad you're thinking about how to discover a DOH service via
DHCP.  (I would recommend including DNS-over-TLS and RDNSS too.)

I don't think your goal conflicts with the existing text, so we can keep
the current draft as is.  The concept of trust is complex and depends on
the situation; the current text is a broad warning that we can easily
adjust and refine in future drafts.

On Mon, Apr 23, 2018 at 10:11 AM, Paul Hoffman <[email-masked]>
wrote:

> Updating RFCs for reasons like this happens all the time in the IETF.
> Given that we don't know when such an update will happen (and I still
> believe it will take a long time to reconcile all of the DNS resolver
> discovery methods), it is better to leave the wording as-is and then update
> it when the complete document comes out.
>
> --Paul Hoffman
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Apr 2018 11:11:13 -0400

>>    and applies equally well to using old-school DNS in such a situation.

Oops, I hadn't intended that to be private.  Sigh.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 23 Apr 2018 15:45:59 -0400

Willem Toorop and I are working on a DHCPv6 draft for discovering DNS-over-TLS, DNS-over-DTLS, DNS-over-DoH. We have been experimenting with different ISC DHCP options to make it as easy to introduce as possible.

Thanks,
Tom

> On Apr 23, 2018, at 10:42 AM, Ben Schwartz <[email-masked]> wrote:
> 
> Mateusz, I'm glad you're thinking about how to discover a DOH service via DHCP.  (I would recommend including DNS-over-TLS and RDNSS too.)
> 
> I don't think your goal conflicts with the existing text, so we can keep the current draft as is.  The concept of trust is complex and depends on the situation; the current text is a broad warning that we can easily adjust and refine in future drafts.
> 
> On Mon, Apr 23, 2018 at 10:11 AM, Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> On Apr 23, 2018, at 5:56 AM, Mateusz Jończyk <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> Updating RFCs for reasons like this happens all the time in the IETF.. Given that we don't know when such an update will happen (and I still believe it will take a long time to reconcile all of the DNS resolver discovery methods), it is better to leave the wording as-is and then update it when the complete document comes out.
> 
> --Paul Hoffman
> 
> https://www.ietf.org/mailman/listinfo/doh <https://www.ietf.org/mailman/listinfo/doh>
> 
>

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Apr 2018 20:05:31 +0000

> Willem Toorop and I are working on a DHCPv6 draft for discovering DNS-over-TLS, DNS-over-DTLS, DNS-over-DoH. We have been experimenting with different ISC DHCP options to make it as easy to introdu…

1) Why just DHCPv6? DHCPv4 still seems relevant to many of us. :-)

2) Is there a mailing list for "DNS resolver discovery" that this is being discussed on?

--Paul Hoffman

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 23 Apr 2018 16:13:48 -0400

> On Apr 23, 2018, at 4:05 PM, Paul Hoffman <[email-masked]> wrote:
> 

We also planned to do IPv4. We started with IPv6 because the option space was more flexible and we could come up with the optimal format. Then we could do IPv4 and make compromises if needed to handle the differences once we had worked out the ideal solution.

> 2) Is there a mailing list for "DNS resolver discovery" that this is being discussed on?

Not that I know of. It’s just private emails between Willem and I. We planned on submitting it to the DHC working group but copying DNS WGs for feedback. I will report back with a forum once we finish writing a few things down. The work is being done on github and we may be able to just use that forum.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Apr 2018 17:32:43 -0400

Tom, it might be worth calling this working group's attention to the discussion that Cullen and I had a the DHC working group meeting a couple of years ago where Cullen was concerned because the working group didn't want to add certain DHCPv6 options, and the working group hadn't clearly articulated why that was.

The answer is that DHCP is good for configuring clients with options in cases where the motivation of the network operator and the consumer of a service or configuration provided by DHCP are in alignment, and not when they are not.   So for example you should never configure a host's SMTP submit server using DHCP, because the network operator may have motives other than being helpful for wanting to relay your SMTP traffic.

On the other hand, the network operator doesn't really have any motivation for sending you a wrong subnet mask, and while they may be interested in snooping your DNS traffic, the fact is that you need a DNS resolver to use the network unless you're going to do full recursive resolution on the host, so you pretty much have to either trust the network operator in this case.   IIRC Cullen rather effectively bashed me over the head with this example.

My point is that the DNS resolver is actually a very chancy example of a sensible DHCP option, and the more you think of the DNS resolver as a trusted service and the less you think of it as network infrastructure, the less sense it makes to configure it with DHCP (or, for that matter, ND).

Configuring a DoH server with DHCP seems to me, as I mentioned in a previous comment, to be a pretty questionable idea.   I do not support this work, because I think that it is counter to the goals of DoH generally.   The goal of DoH is to subvert the network operator's intentions with respect to DNS traffic.   That's completely incompatible with configuring DoH with DHCP (or RA).

The inability to reach your configured, trusted DoH server from the local network is an attack on the host.   You are trusting the thing that is attacking you to provide you with configuration information.   That just doesn't make sense.

If you really want to do this, the first step is to clearly state the threat model that you are addressing by providing DoH in this way, and to discuss all the threat models you are _not_ addressing by doing so.   And then compare this to the threat model that DoH-without-DHCP addresses, and see if there is actually any value added by the other solution.

It may be that there is value in automatically configuring DoH servers using network infrastructure.   If that's the case, we should try to clearly understand what the trust model is for such a configuration before proceeding to design the bits on the wire. :)

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 23 Apr 2018 17:40:10 -0400

> On Apr 23, 2018, at 5:32 PM, Ted Lemon <[email-masked]> wrote:
> 

Ted,
	I totally agree with your reservations and limited scope of applicability. I think that in certain environments, it does make sense and we should clearly state what we think can and cannot be accomplished through these options. We will try to make a logical case for where this is useful but will concede to the wishes of the community if they think it is not useful.

Thanks,
Tom

---

From: Paul Hoffman <[email-masked]>
Date: Mon, 23 Apr 2018 22:06:27 +0000

On Apr 23, 2018, at 2:32 PM, Ted Lemon <[email-masked]> wrote:
> The goal of DoH is to subvert the network operator's intentions with respect to DNS traffic.

Can you point to the part of the draft (which is in WG Last Call) where it says that? If so, I promise to fix it because that is not an intended goal.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Apr 2018 20:27:07 -0400

> Can you point to the part of the draft (which is in WG Last Call) where it says that? If so, I promise to fix it because that is not an intended goal.

From the WG Charter:

The primary focus of this working group is to develop a mechanism that
provides confidentiality and connectivity between DNS clients (e.g., operating
system stub resolvers) and recursive resolvers. 

From the document's introduction:

   Two primary uses cases were considered during this protocol's
   development.  They included preventing on-path devices from
   interfering with DNS operations and allowing web applications to
   access DNS information via existing browser APIs in a safe way
   consistent with Cross Origin Resource Sharing (CORS) [CORS].  There
   are certainly other uses for this work.

The first of these two use cases is to subvert the intentions of the network operator. Providing confidentiality and connectivity is as well.   Of course, a less provoking way of saying what I said might be "to prevent abuse by network operators," but it's kind of a toss-up.

Anyway, if you think this is not the goal of the document, there may be some kind of communication problem here to resolve... :)

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 24 Apr 2018 00:43:11 +0000

On Apr 23, 2018, at 5:27 PM, Ted Lemon <[email-masked]> wrote:
> The first of these two use cases is to subvert the intentions of the network operator.

There are plenty of network operators who want to prevent on-path devices from interfering with DNS operations, and there are plenty who don't want that. 

> Providing confidentiality and connectivity is as well.  Of course, a less provoking way of saying what I said might be "to prevent abuse by network operators," but it's kind of a toss-up.

It's focusing on a subset of "network operators" and pretending that it is the complete set.

> Anyway, if you think this is not the goal of the document, there may be some kind of communication problem here to resolve... :)

So far, you're the only one to have had it, so hopefully this message fixes it.

--Paul Hoffman

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Apr 2018 21:09:36 -0400

> It's focusing on a subset of "network operators" and pretending that it is the complete set.

Argh.   No.   When you are examining a threat model, there is no difference between "the network operator could be attacking me in a way I can't detect" and "the network operator _is_ attacking me in a way I can't detect."

The point of what I was saying is not that network operators are evil.  Many of the things that they do to the DNS that DoH would prevent are actually to the benefit of the average end user.

The point also isn't that there is no use for DoH other than subverting the intentions of operators.

But very clearly, that is one of the things that it can do, and it is very clearly stated in the charter as the primary goal.