Subject: [DNSOP] Draft for dynamic discovery of secure resolvers

From: Marek Vavruša <[email-masked]>
Date: Sat, 18 Aug 2018 14:17:16 -0700

Hi,

this is a bit off topic, but I figured it would be useful to solicit
some early feedback. The current status is that for secure (as in
RFC7858 DoT or DoH) resolvers is that there's no discovery mechanism,
and it's also out of scope for [0]. At the same time we're seeing real
world deployment of clients which either:

a) Probe port 853 and use DoT in opportunistic profile, or probe 443
and trust WebPKI
b) Statically configure ADN and/or SPKI pins with well known public resolvers

This approach works if there's someone maintaining the statically
configured information, as with the dnscrypt-proxy stamp lists [1].
However in most networks the default resolver configuration is pushed
through DHCP, so it's the network operator that's in charge for
providing default DNS resolver configuration (unless the user is a DNS
aficionado and overrides it), but there's currently no good way to
provide information required to identify and securely bootstrap a
connection to a resolver using DoT or DoH.

This draft adds an option to provide a capability list for each
configured resolver. The three defined capabilities are TLS with SPKI
pin, TLS with ADN, HTTPS. The idea is that DHCP clients reads this
information and stores it similarly to resolver list and domain search
path for applications to read. Another possible solution for this is
to use the system of stamps from dnscrypt-proxy, but it's probably
less legible for clients and duplicates information that's already in
the recursive DNS nameservers DHCPv4/v6 option.

The draft does not change the trust model, an end-user or an
application can still disregard DNS recursive nameserver list from
DHCP, for better or worse.

Here's the draft:
https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt

Marek

[0]: https://trac.tools.ietf.org/html/rfc8310#section-7.3.1
[1]: https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-resolvers.md

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 17:22:53 -0400

DHCP authentication doesn't exist.   We already rejected a draft that
described how to set up DoH with DHCP.   Yours is a little more
complicated, but doesn't seem any less dangerous.   Before you go any
farther on this, you might ask yourself a couple of questions:

1. Why is DoH being used?
2. What is the thread model that DoH is addressing?
3 How does adding this configuration mechanism impact DoH's ability to
address that threat model?

On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša <
mvavrusa=[email-masked]> wrote:

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 14:46:49 -0700

> address that threat model?

the DoH use case is for web users and web apps who do not trust their 
network operator and who are not trusted by their network operator, so 
it's a policies-in-the-night model where data can be imported from The 
Web without approval or permission or control or observability by a 
network operator. it is in other words a thin DNS-only way to do what 
Tor does.

as a network operator, i oppose this thinking. i predict a long war in 
which web users and apps who want to use DoH to reach an external DNS 
resolver will be treated as attackers, and either banned or blocked. in 
some parts of the world such use will be illegal and even punishable, 
much as Tor is today.

this is what happened after edward snowden flew to hong kong: the 
pendulum swung so far the other way that many of us saw only absurdity.

the possibility that large CDN operators will colo a DOH endpoint with 
their high-value hosting, in order to discourage network operators from 
blocking it, raises the stakes. _i_ will block it. most corporate 
networks will block it in some form. some countries will block it. no 
DNS content will enter my network without having passed through my RPZ 
rules. if a CDN operator wants to play "chicken", i guess that we will.

-- 
P Vixie

---

From: Marek Vavruša <[email-masked]>
Date: Sat, 18 Aug 2018 14:58:39 -0700

Hi Ted,

thanks for comments. As said, the draft doesn't try to change the
trust model or fix DHCP authentication, it merely offers network
operators the ability to advertise secure resolvers for their network.
The added "danger" is that recipient inherently trusts the
information.

On Sat, Aug 18, 2018 at 2:22 PM, Ted Lemon <[email-masked]> wrote:
> described how to set up DoH with DHCP.   Yours is a little more complicated,
> but doesn't seem any less dangerous.   Before you go any farther on this,
> you might ask yourself a couple of questions:
>

The DoT and DoH are being used because they're both either standard or
on a standards track and have deployed client software.

> address that threat model?

It does not. In both cases, determining whether the resolver (or its
capabilities) provided by a DHCP server can be trusted is up to the
client.
The current model is that either OS or applications like browsers
install a curated CA bundle with CA's the client should trust.
When a DNS stub resolver receives a request, it looks into the
resolv.conf (simplifed) and picks a resolver to send query to.
Currently the most common method is to pick first, but it might prefer
resolvers with secure capabilities first.
If a resolver is advertised as secure, the stub resolver may do a TLS
handshake and check the certificate.
Now at this step, it may:

a) only trust certificates issued by a CA trusted by the application
with the resolver IP address in SAN (trust system configuration)
b) ditto, but certificates with advertised ADN in SAN or matching
SPKI pin (this presumes the client trusts DHCP offering, or is okay
with TOFU)
c) bail and talk to the resolver over port 53

In a), the resolver can be trusted. In both b) and c) the trust in the
resolver doesn't really change from current status until DHCP
authentication happens, but the query stream is hidden from other
devices on the same network. Either way, the benefit is that stub
resolver can make a decision based on a multitude of factors. Is there
a merit in this, or am I perhaps missing something?

Marek

>
> On Sat, Aug 18, 2018 at 5:17 PM, Marek Vavruša
> <mvavrusa=[email-masked]> wrote:
>>
>> Hi,
>>
>> [1]:
>> https://download.dnscrypt.info/dnscrypt-resolvers/v2/public-resolvers.md
>>

---

From: "John Levine" <[email-masked]>
Date: 18 Aug 2018 18:00:24 -0400

In article <[email-masked]> you write:
> it is in other words a thin DNS-only way to do what Tor does.

Considering what we know about Tor, that is not encouraging.

It seems to me that that most likely scenario for DoH is in javascript
apps that need to look up something other than an A record (SRV
perhaps) so the most likely DoH server is the one that the javascript
came from.  No fancy configuation needed for that.

R's,
John

---

From: Marek Vavruša <[email-masked]>
Date: Sat, 18 Aug 2018 15:01:35 -0700

Hi,

thanks for comments. This draft has little to do with DoH (the primary
focus is DoT), and its comparison to other technologies. It's about
network operator being able to advertise that its recursive server
supports DNS on more than just port 53. Please let's stay at least a
bit on topic.

Marek

On Sat, Aug 18, 2018 at 2:46 PM, Paul Vixie <[email-masked]> wrote:
> network operator and who are not trusted by their network operator, so it's
> a policies-in-the-night model where data can be imported from The Web
> without approval or permission or control or observability by a network
> operator. it is in other words a thin DNS-only way to do what Tor does.
>
> as a network operator, i oppose this thinking. i predict a long war in which
> web users and apps who want to use DoH to reach an external DNS resolver
> will be treated as attackers, and either banned or blocked. in some parts of
> the world such use will be illegal and even punishable, much as Tor is
> today.
>
> this is what happened after edward snowden flew to hong kong: the pendulum
> swung so far the other way that many of us saw only absurdity.
>
> the possibility that large CDN operators will colo a DOH endpoint with their
> high-value hosting, in order to discourage network operators from blocking
> it, raises the stakes. _i_ will block it. most corporate networks will block
> it in some form. some countries will block it. no DNS content will enter my
> network without having passed through my RPZ rules. if a CDN operator wants
> to play "chicken", i guess that we will.
>
> --
> P Vixie
>

---

From: bert hubert <[email-masked]>
Date: Sun, 19 Aug 2018 01:03:19 +0200

> 2. What is the thread model that DoH is addressing?

That not yet enough of the internet has been centralized on big cloud
providers in foreign jurisdictions, I think.

(this post does get DNS operational after a few paragraphs)

It borders on the ridiculous that we have CDNs and browser vendors pushing
this service for free, at great cost, claiming they are doing it out of the
goodness of their hearts.

I can imagine the board meeting already in the SOMA district in SF. Big
powerpoint presentation. "We're going to allocate resources to enhance the
privacy of people who aren't even our customers". Investor representatives
look up and ask "why??", well goes the response, because we lie awake at
night that some providers are attempting to monetize DNS, and we can't let
this horrible invasion of privacy continue unabated!

Meanwhile said users are browsing webpages laden with trackers by dozens of
companies already monetizing that traffic. 

Furthermore, the DNS of >600 million people is already hosted by service
providers not allowed to monetize DNS.  So for a ton of people, we're moving
DNS from highly regulated telecommunications companies to a VC-backed CDN
that cooperates closely with heavily censoring regimes in order to get
business.

Additionally, the operational community is up in arms since this move will
break their intranet, their local security policies, their VPN domain
overrides and their threat monitoring. 

The CDN providers have also made it clear they will colocate the DoH service
on IP addresses that carry "unblockable" content, forcing system
administrators into a Solomon judgment: shall we take down the CDN that
carries 'jquery' and break half the internet, or shall we allow
uninspectable DNS? 

In this way, popular content serves as a human shield to protect DoH against
blocking.

Malware authors will surely love this dilemma too and be sure to move all
their DNS lookups to the colocated service - where we can never spot them.

But apparently the interest in enhancing users privacy by moving DNS to a
third party, by default, is so large that all these worries do not matter. I
find this very hard to believe.

(Mind you - Mozilla is on record that they want to turn this on by default. 
There has been some weaselwording around this on Twitter by people claiming
not to speak for Mozilla, but no denial.  So for now, we can safely assume
they are seriously intending to turn on DoH by default -
https://blog.ungleich.ch/en-us/cms/blog/2018/08/04/mozillas-new-dns-resolution-is-dangerous/
)

I've been trying to understand what everyone is up to, but I find myself in
a 'Sherlock Holmes' situation where all reasonable explanations don't work.
Why is there this massive push to enable DoH by default?

The CDN providers in question must adhere to strict privacy policies and
allow themselves to be audited. So there's no immediate monetization
possible.

However, looking up all domain names with CDN provider A does mean users
would then, by default, have to access all sites hosted at CDN provider B
through provider A. 

This is an area where "rent seeking" https://en.wikipedia.org/wiki/Rent-seeking
is entirely possible. 

And lo, we are already seeing it! CDN Provider B relies on EDNS Client
Subnet for some of the largest service providers in the world and CDN
provider A is not going to supply those 24 bits of address to CDN provider
B!

Immediately, rolling out DoH by default is going to hurt CDN provider B.

I realise I'm screaming into the void a bit, but whenever someone says
"centralise this stuff on me, it will be better, and I'm spending big on it
for the love of your privacy", I am worried. 

Especially when such a move will incidentally kill intranets, VPNs, split
horizon, DNS monitoring & DNS malware detecion and blocking. 

So to round this off - I am not clear what threat
DoH-in-the-browser-to-a-third-party is protecting us against.

	Bert

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 19:12:57 -0400

How will you block it?

On Sat, Aug 18, 2018 at 5:46 PM, Paul Vixie <[email-masked]> wrote:

> some parts of the world such use will be illegal and even punishable, much
> as Tor is today.
>
> blocking it, raises the stakes. _i_ will block it. most corporate networks
> will block it in some form. some countries will block it. no DNS content
> will enter my network without having passed through my RPZ rules. if a CDN
> operator wants to play "chicken", i guess that we will.
>
> --
> P Vixie
>
>

---

From: bert hubert <[email-masked]>
Date: Sun, 19 Aug 2018 01:21:06 +0200

> How will you block it?

So just to make this a bit more colorful, DoH allows servers to push
unsollicited DNS responses, which the browser is then free to put in its DNS
cache.

This allows the DoH endpoint to hop around at will, or even have a whole
stash of IP addresses ready as alternates.

	Bert

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 19:54:09 -0400

Yup.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 20:03:42 -0400

Marek, forgive me for being blunt, but your reply was completely
non-responsive.   DoH and DoT are being used because they address a threat
model, or because, as Bert rather bluntly put it, they allow content
providers to study our query stream.   They are not being used "because
they are standards track documents."   If you don't have any reason other
than that to use DoH or DoT, then you shouldn't use them.

You say that your proposal does not impact DoT's ability to address the
threat model or use case that is the reason it is being used.   But this is
doesn't make sense to me.   The trust model for DoT and DoH right now is
that they are configured by the user for the user's reasons, or by the
service provider for the service provider's reasons.   You are proposing
that whatever configuration the user or service provider has set up be
replaced by information received by DHCP, and that "DHCP authentication",
which doesn't exist, be used to validate this information.   This is a
completely different trust model than the current trust model.   Maybe it's
a good idea, maybe it's a bad idea, but it's completely different.   So you
need to figure out the existing trust model and figure out how your
proposal impacts that trust model.   To define a DHCP option before you've
done this is putting the cart before the horse.

On Sat, Aug 18, 2018 at 5:58 PM, Marek Vavruša <[email-masked]>
wrote:

> complicated,

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 17:33:05 -0700

> supports DNS on more than just port 53. Please let's stay at least a

i think stubs should try to negotiate persistent tcp/853 for every 
address they receive from dhcp, and if they can't, they should fall back 
to doing whatever they did before, like try udp/53, and so on.

-- 
P Vixie

---

From: Marek Vavruša <[email-masked]>
Date: Sat, 18 Aug 2018 17:33:19 -0700

On Sat, Aug 18, 2018 at 5:03 PM, Ted Lemon <[email-masked]> wrote:
> providers to study our query stream.   They are not being used "because they
> are standards track documents."   If you don't have any reason other than
> that to use DoH or DoT, then you shouldn't use them.

No worries, I hoped I described the use case, but perhaps not well enough.

> service provider for the service provider's reasons.   You are proposing

This is the issue that the draft is trying to solve. The service
provider doesn't have a way
to configure DoT on the stub resolver. This problem is described in
https://tools.ietf.org/html/rfc8310#section-6.7
What I'm trying to address more specifically is
https://tools.ietf.org/html/rfc8310#section-7.3

> which doesn't exist, be used to validate this information.   This is a

The "DHCP authentication" does exist, I believe you're referring the
deployment status.
I'm happy if we say the draft must depend on RFC3315, or discuss the
trustworthiness of the responses,
but surely there must be a way forward if we want to keep the
recursive DNS (last mile) decentralized and free from tampering.

> need to figure out the existing trust model and figure out how your proposal
> impacts that trust model.   To define a DHCP option before you've done this
> is putting the cart before the horse.

I described one possible way how clients could interpret the
advertised information using a trusted CA bundle.
At the very least, if my ISP or office network advertises resolvers on
port 853, using those is arguably better than
the same resolver on port 53.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 17:37:13 -0700

> How will you block it?

at work we'll probably firewall all outbound tcp and require the use of 
proxies, which will do some kind of payload inspection.

at home i don't know yet but i'll likely just blacklist every known DOH 
endpoint, and tell my family, if you want netflix, go get a hotel room.

i will _not_ have my security policy dictated to me by mozilla and 
cloudflare. "my network; my rules" is how it was when people were suing 
me for publishing the MAPS RBL back in the 1990's, and it's how it'll be 
today.

-- 
P Vixie

---

From: Marek Vavruša <[email-masked]>
Date: Sat, 18 Aug 2018 17:38:27 -0700

On Sat, Aug 18, 2018 at 5:33 PM, Paul Vixie <[email-masked]> wrote:
> i think stubs should try to negotiate persistent tcp/853 for every address
> they receive from dhcp, and if they can't, they should fall back to doing
> whatever they did before, like try udp/53, and so on.
>
> --
> P Vixie

I agree, this works in the opportunistic profile or with an IP
certificate and trust in CA model.
The pros and cons of this are described in
https://tools.ietf.org/html/rfc8310#section-7.2

It doesn't work for dynamic configuration of ADN or SPKI pins.

Marek

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 17:38:35 -0700

> stash of IP addresses ready as alternates.

perhaps the thought is that this will cause corporate security 
operators, and the great firewall of china's operator, to just say oh 
what the heck we've lost that war let's just let it happen.

if so, that thought signals derangement on the part of the thinker.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 20:48:00 -0400

> https://tools.ietf.org/html/rfc8310#section-7.3

 The document explicitly says that it doesn't have a trust model for DHCP.

> The "DHCP authentication" does exist, I believe you're referring the

No, I'm referring to it doesn't exist.   There is no deployable DHCP
authentication.   The DHC working group tried to come up with one, and
ultimately concluded that it was not worth it, because the only thing that
should ever be trusted from a DHCP server is information about the local
network.   DoH and DoT are out of scope for DHCP according to this
reasoning.   Bear in mind that we were more optimistic about authentication
when we did RFC 3315.   RFC 8415, which is in AUTH48, and which supersedes
RFC3315, is not as optimistic, and only provides for authentication using
IPsec between server and relay, and authentication for the purpose of doing
Reconfigure; this authentication is not sufficient to provide assurances of
trustworthiness.   It's about as secure as a TCP sequence number.

> recursive DNS (last mile) decentralized and free from tampering.

There is a way forward: seriously figure out the threat model.   Tom
Pusateri and another author already did a DHCP document; the reason we
didn't advance it is that we weren't able to come up with a threat model
where configuring DoT or DoH made sense.   Until someone does that, there
is no point in doing further work on a DHCP option.   If we do do further
work on a DHCP option, Tom's document is more complete than yours.

---

From: Marek Vavruša <[email-masked]>
Date: Sat, 18 Aug 2018 17:53:09 -0700

On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon <[email-masked]> wrote:
> where configuring DoT or DoH made sense.   Until someone does that, there is
> no point in doing further work on a DHCP option.   If we do do further work
> on a DHCP option, Tom's document is more complete than yours.

Can you share the link for the draft for a reference?

Marek

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 17:54:17 -0700

my threat model is intruders or eavesdroppers on the path between me and 
my rdns. i'd like the dhcp announcement to include a tcp/853 signal 
along with a pre-shared key or the hash thereof. the benefit would be 
that if my rdns network path is less secure than my dhcp network path, 
i'll improve the former by not using traditional udp/53. does that help?

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 21:03:52 -0400

https://tools.ietf.org/html/draft-ietf-dhc-rfc3315bis-13

On Sat, Aug 18, 2018 at 8:53 PM, Marek Vavruša <[email-masked]>
wrote:

> >> > threat model or use case that is the reason it is being used.   But
> this
> >> > is

---

From: Tom Pusateri <[email-masked]>
Date: Sat, 18 Aug 2018 21:09:13 -0400

> On Aug 18, 2018, at 8:53 PM, Marek Vavruša <mvavrusa=[email-masked]> wrote:
> 
> On Sat, Aug 18, 2018 at 5:48 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:

Marek,
	I sympathize with your desire to deploy DNS over TLS. That was the motivation for Willem Toorop and I to go down this road and present it at Montréal IETF DRIU BOF. Ted challenged me as well but I didn’t understand his point before I presented our work. Ted gave an excellent rebuttal talk after mine that was very clear about how DHCP should really only be used to bootstrap configuration information enough to then talk to more trusted services due to lack of authentication and lack of trustworthiness when connecting to unknown networks.

You should first of all go listen to Teds talk (not a TED Talk) from the DRIU BOF. The video is here: https://www.youtube.com/watch?v=cfEX8zuoRAA <https://www.youtube.com/watch?v=cfEX8zuoRAA>
Ted’s talk starts at 33:18.

Willem and my draft is here:

https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00>

My talks on threats and this draft are in the archives of the DRIU BOF and in the same video as Ted.

Aside from Ted, there was a strong consensus in the room to not adopt our draft. You can listen to the comments at the microphone for more information.

Thanks,
Tom

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 21:08:35 -0400

The thing is that most devices don't connect to just one network.   So
while your devices on your network can certainly trust port 853 on your
network, when they roam to other networks, they have no reason to trust
it.   If you have devices that never roam to other networks, that's fine,
but we have to design for the more general case.   There's no way with DHCP
for the device to tell that it's connected to a particular network, other
than matching IP addresses, which isn't a great idea.

On Sat, Aug 18, 2018 at 8:54 PM, Paul Vixie <[email-masked]> wrote:

> my rdns. i'd like the dhcp announcement to include a tcp/853 signal along
> with a pre-shared key or the hash thereof. the benefit would be that if my
> rdns network path is less secure than my dhcp network path, i'll improve
> the former by not using traditional udp/53. does that help?
>

---

From: Marek Vavruša <[email-masked]>
Date: Sat, 18 Aug 2018 18:10:48 -0700

Thanks Tom, this is what I was asking for. I'll take a look!

On Sat, Aug 18, 2018 at 6:09 PM, Tom Pusateri <[email-masked]> wrote:
>
>
> On Aug 18, 2018, at 8:53 PM, Marek Vavruša
> I sympathize with your desire to deploy DNS over TLS. That was the
> motivation for Willem Toorop and I to go down this road and present it at
> Montréal IETF DRIU BOF. Ted challenged me as well but I didn’t understand
> his point before I presented our work. Ted gave an excellent rebuttal talk
> after mine that was very clear about how DHCP should really only be used to
> bootstrap configuration information enough to then talk to more trusted
> services due to lack of authentication and lack of trustworthiness when
> connecting to unknown networks.
>
> You should first of all go listen to Teds talk (not a TED Talk) from the
> DRIU BOF. The video is here: https://www.youtube.com/watch?v=cfEX8zuoRAA
> https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00
>
> Aside from Ted, there was a strong consensus in the room to not adopt our
> draft. You can listen to the comments at the microphone for more
> information.
>
> Thanks,
> Tom
>
>
>
>
>

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 18:21:18 -0700

Ted Lemon wrote:
> it.

that's far afield of my stated use-case.

if i receive advice and pre-shared key, concerning tcp/853, from my dhcp 
server, the tcp/853 service i'm advised to use may not be on my own 
network, it could be part of my corporate VPN, or an anycasted 
commercial service, or almost anywhere else.

in that case, my DHCP transaction was local, and my resulting TCP/853 
transactions won't be local. and in that case i will have a greater 
reason to trust the pre-shared key and the TCP/853 advice because of 
where i received it, than i would have reason to trust privacy or 
integrity of the path to a UDP/53 + TCP/53 ("traditional DNS") server.

roaming is another matter, because in those cases, i'll speak DHCP to 
some new network provider, and will receive some advice concerning an 
RDNS service from that new DHCP transaction, which will obviate any 
previous advice, or whether i took that advice, or how trustworthy that 
advice turned out to be.

> ... If you have devices that never roam to other networks, that's
> fine, but we have to design for the more general case.   There's no way
> with DHCP for the device to tell that it's connected to a particular
> network, other than matching IP addresses, which isn't a great idea.

if i'm not roaming, i won't receive RDNS advice from the other DHCP 
servers that i never come into contact with. this seems a non-sequitur.

if i am roaming, then anyone who hands me an address via DHCP should 
feel free to advise me as to what DNS service i use, including a TCP/853 
service for which a pre-shared key may be needed. because the network 
operator may forbid and prevent the use of other DNS services which i 
may prefer, it would be wise for me to listen to that advice, and 
consider following it, especially if my usual service can't be reached 
while operating on said network.

roaming is off-topic. DHCP authentication and integrity is off-topic. 
this is a simple proposal to allow a network operator to include TCP/853 
("DoT") advice including pre-shared keys in their DHCP responses. it 
ought to be drama-free.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 21:37:23 -0400

On Sat, Aug 18, 2018 at 9:21 PM, Paul Vixie <[email-masked]> wrote:
> network, it could be part of my corporate VPN, or an anycasted commercial
> service, or almost anywhere else.
>
> transactions won't be local. and in that case i will have a greater reason
> to trust the pre-shared key and the TCP/853 advice because of where i
> received it, than i would have reason to trust privacy or integrity of the
> path to a UDP/53 + TCP/53 ("traditional DNS") server.
>
> roaming is another matter, because in those cases, i'll speak DHCP to some
> new network provider, and will receive some advice concerning an RDNS
> service from that new DHCP transaction, which will obviate any previous
> advice, or whether i took that advice, or how trustworthy that advice
> turned out to be.
>

If you are trusting a "pre-shared key," why not just pre-share the DoT
server information?   If you are using the pre-shared key as a way to
validate a server whose IP address may change over time, why not configure
the pre-shared key with a domain name?

> if i am roaming, then anyone who hands me an address via DHCP should feel
> free to advise me as to what DNS service i use, including a TCP/853 service
> for which a pre-shared key may be needed. because the network operator may
> forbid and prevent the use of other DNS services which i may prefer, it
> would be wise for me to listen to that advice, and consider following it,
> especially if my usual service can't be reached while operating on said
> network.
>
> roaming is off-topic. DHCP authentication and integrity is off-topic. this
> is a simple proposal to allow a network operator to include TCP/853 ("DoT")
> advice including pre-shared keys in their DHCP responses. it ought to be
> drama-free.

The reason it's not drama-free is because you can't just hand-wave the
threat model.   What you just said is a fine way for you, Paul Vixie, a
knowledgeable user, to configure your device, but I can't explain this
threat model to a typical end user, and they have no basis for deciding
what they should do.   You mention the GFWoC, and that's certainly a use
case we need to consider, but we also need to consider the use case of the
malicious coffee shop network that wants to harvest your passwords.   I
don't know if you have friends who've been taken by this scam, but I have,
and it cost them a *lot.*   So how does my host tell the GFWoC from the
malicious coffee shop server?   Assume that it can't ask me to figure it
out—it has to follow some decision heuristic that is programmed in at the
factory.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 18:57:26 -0700

Ted Lemon wrote:
...
> server information? ...

because my preferred DoT server may not work inside someone else's network.

...
> case we need to consider, but we also need to consider the use case of
> the malicious coffee shop network that wants to harvest your passwords.

i thought we'd spent 19 years on DNSSEC to deal with that threat, along 
with DANE and TLS 1.3. if it's still an unsolved problem, then i dare 
say that we won't be fixing it by telling people not to use RDNS stub 
servers that are recommended to them by their address provider via DHCP.

>   I don't know if you have friends who've been taken by this scam, but I
> have, and it cost them a /lot./   So how does my host tell the GFWoC
> from the malicious coffee shop server?   Assume that it can't ask me to
> figure it out—it has to follow some decision heuristic that is
> programmed in at the factory.

when i go to defcon, my software updates all fail, because signatures 
are wrong. luckily, the vendors of my software understand this problem. 
even my bios vendor signs their updates in a way that the recipient can 
tell there's a forgery. i would _not_ expect to be able to mitigate any 
of those risks by changing who i received my DNS responses from.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Sat, 18 Aug 2018 22:43:06 -0400

Well, if that's true, Paul, then I guess DNS filter lists are totally
unnecessary and you should stop working on that.   Maybe you already have?

On Sat, Aug 18, 2018 at 9:57 PM, Paul Vixie <[email-masked]> wrote:

> with DANE and TLS 1.3. if it's still an unsolved problem, then i dare say
> that we won't be fixing it by telling people not to use RDNS stub servers
> that are recommended to them by their address provider via DHCP.
>
> when i go to defcon, my software updates all fail, because signatures are
> wrong. luckily, the vendors of my software understand this problem. even my
> bios vendor signs their updates in a way that the recipient can tell
> there's a forgery. i would _not_ expect to be able to mitigate any of those
> risks by changing who i received my DNS responses from.
>
> --
> P Vixie
>
>

---

From: Paul Vixie <[email-masked]>
Date: Sat, 18 Aug 2018 22:03:53 -0700

> unnecessary and you should stop working on that.   Maybe you already have?

see https://dnsrpz.info/ for more details on DNS Firewalls. of course, 
nominum was selling something like this ten years ago, and others have 
also developed similar capabilities in-house. this is a published spec 
so as to allow an unlimited number of subscribing defenders to choose 
from an unlimited number of publishing suppliers using one "language".

it's possible that others who have not begun to use RDNS as a perimeter 
defense do not understand why some of us can't allow every app or 
browser or user to transmit their own dns requests to outside servers. 
that is, we as network operators want to prevent some lookups from 
succeeding, in order to keep certain known-malicious activities frozen.

you may be excluding a middle in your analysis of what i've said. if a 
user or app can't get the DNS service they prefer, they should either 
use a different network, or shut off and go count mountain butterflies. 
in no event should they seek a bypass to the network operator's security 
policy. "their network, their rules."

-- 
P Vixie

---

From: Paul Wouters <[email-masked]>
Date: Sun, 19 Aug 2018 01:12:24 -0400

> On Aug 19, 2018, at 01:03, Paul Vixie <[email-masked]> wrote:
> 
> . this is a published spec so as to allow an unlimited number of subscribing defenders to choose from an unlimited number of publishing suppliers using one "language".

A draft spec that unfortunately isn’t being moved along so IETF can do a bis document to improve it to work with dnssec.

> it's possible that others who have not begun to use RDNS as a perimeter defense

Perimeters don’t exist anymore and networks can’t be trusted.

Paul W

---

From: manu tman <[email-masked]>
Date: Sat, 18 Aug 2018 23:42:15 -0700

I am going to focus back on the draft itself. While the discussion around
centralizing DNS to 3rd party vs local ISP (or any other alternatives) is
worth having, it is a fact that most people get their DNS server set using
DHCP.
the current state is that all you will get are addresses that you can use
to query DNS over port 53.

With the advent of recursive DNS servers that can support encryption, it
will be useful to signal that to stub resolver. Some ISPs may want to
provision their CPE to advertise DoT to their recursive resolvers with cert
pining. Other ISPs in regions that heavily offload their DNS to so X.X.X.X
provider, would be able to let their customer use the service from such
providers, but over an encrypted channel. "power users" may want to
configure their home router to publish a set of DNS servers to be used
using DoT or DoH.
This is definitely not a bullet proof solution, but it seems better than
what we currently have and with minimal protocol change (just adding an
option).
The way I read this, the network owner that in the past would have made the
hosts in their network use unencrypted DNS, will now be able to easily
promote encrypted DNS.

As for feedback on the draft options.
- Section 2.3: Why DoH has no option data? The IP from the DNS recursive
name server option merely provide an IP to connect to. DoH server may have
a cert that will validate for a hostname. The endpoint may or may not be
/dns-query . How about alternate ports? It seems a having the URI as part
of the data would be useful ( e.g https://dnsserver.example.net/dns-query ,
https://10.10.10.10:8443/dns-query , https://2001:DB8::1/doh ...)
- the draft as is, assumes that port 853 will be used for DoT, 443 for DoH.
Being able to provide alternate ports could be a plus
- It is not clear to me if the options apply to all nameservers from the
dns recursive nameserver option, or if there needs to be 1 option for each
nameserver. I could for instance have nameserver1 which does DoT + DoH
while nameserver2 does none. In this case, I would get option 147 with
option len of 2 for the first server, followed by option 147 with option
len of 0 for the second one.
- A DHCP option should be able to be set multiple time, so one can
configure TLS_SPKI with multiple values. May be useful for rotations and
such.

Manu

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 19 Aug 2018 13:18:06 +0000

In a DOCSIS network, for whatever that's worth, the link from the home (cable modem) to the next hop (CMTS) is encrypted. It is then usually just one or two hops within the ISP's regional network to the recursive DNS (in some cases DNSSEC-validating, as in our case). So I suppose that the threat model in this example is presumably someone (1) eavesdropping on the relatively short path between CMTS and resolver or (2) modifying non-DNSSEC-validated responses - and that's does not seem like a very high risk threat IMO, given all the other potential and real threats lurking around on the Internet. 

In any case, if a user felt it was a high risk then letting their stub pick up the same resolver address (such as via DHCP) and choose to use TLS to secure the DNS query stream to the same resolvers would seem like an easy solution. But I am sure there are countries where this might carry a higher risk, in which case users have traditionally used Tor, VPNs, etc. In the latter (user-directed) case this suggests an implementation model where an end user optionally turns something on rather than a 3rd party deciding it should always be on (given the likely downsides of this operationally).

- Jason

On 8/18/18, 8:54 PM, "DNSOP on behalf of Paul Vixie" <[email-masked] on behalf of [email-masked]> wrote:

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 19 Aug 2018 13:29:16 +0000

On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" <[email-masked] on behalf of [email-masked]> wrote:
    Especially when such a move will incidentally kill intranets, VPNs, split
    horizon, DNS monitoring & DNS malware detecion and blocking. 

It seems to me that the underlying protocol is separable from the operational implementation, and the latter case is likely where most of the concerns lie. Thus, the issue is likely less DoH itself but rather how it is likely to be deployed.

I am considering starting work on a draft along the lines of 'potential impacts of DoH deployment' to try to document some of this, if for nothing else than to organize my own thinking on the matter. This is because I also share concern, given the apparent deployment model, around what may break in enterprise networks, malware detection & remediation, walled garden portals during service provisioning, parental controls, and the impacts of eliminating other local policies. The CDN-to-CDN competition case is an interesting one as well, with respect to passing EDNS client subnet or not. 

JL

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 10:30:45 -0400

I think this would be a better place to start than proposing a solution.
 It's pretty clear that the thinking in this space is all over the map.

On Sun, Aug 19, 2018 at 9:29 AM, Livingood, Jason <
[email-masked]> wrote:

> On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert" <
> [email-masked] on behalf of [email-masked]> wrote:
> It seems to me that the underlying protocol is separable from the
> operational implementation, and the latter case is likely where most of the
> concerns lie. Thus, the issue is likely less DoH itself but rather how it
> is likely to be deployed.
>
> I am considering starting work on a draft along the lines of 'potential
> impacts of DoH deployment' to try to document some of this, if for nothing
> else than to organize my own thinking on the matter. This is because I also
> share concern, given the apparent deployment model, around what may break
> in enterprise networks, malware detection & remediation, walled garden
> portals during service provisioning, parental controls, and the impacts of
> eliminating other local policies. The CDN-to-CDN competition case is an
> interesting one as well, with respect to passing EDNS client subnet or not.
>
> JL
>
>
>

---

From: Doug Barton <[email-masked]>
Date: Sun, 19 Aug 2018 09:43:21 -0700

On 08/18/2018 06:08 PM, Ted Lemon wrote:
> it.   If you have devices that never roam to other networks, that's 

Ted,

I'd like to turn your question back to you. What threat model are you 
protecting the user from by not allowing a DHCP option to use a DOH or 
DOT server?

It seems to me that in the overwhelming majority of cases (near 100%) 
the user is going to get their local resolver from the DHCP server, 
whether they are on a trusted network (like work or home), or roaming at 
Eve's Coffee Shop.

So either you have a sophisticated user who has preconfigured their own 
resolver and ignores the DHCP setting, or you have the typical user who 
doesn't understand how any of this stuff works, and therefore has 
implicit "trust" regarding the local network and the settings from the 
DHCP server.

Given that (and feel free to tell me if I've missed something), what 
harm can come to the user if the resolver that they are already trusting 
can also be accessed over DOH or DOT?

Doug

---

From: Doug Barton <[email-masked]>
Date: Sun, 19 Aug 2018 10:02:15 -0700

On 08/19/2018 06:18 AM, Livingood, Jason wrote:
> So I suppose that the threat model in this example is presumably someone (1) eavesdropping on the relatively short path between CMTS and resolver or (2) modifying non-DNSSEC-validated responses - and that's does not seem like a very high risk threat IMO, given all the other potential and real threats lurking around on the Internet.

Personally I see securing the path from the stub to the resolver as a 
good step in the ultimate goal of encrypting all of the things. :) I'd 
like to see the traffic from the resolver to the authorities encrypted 
as well, along with all the other traffic on the Internet.

In years past people like me who pushed "encrypt, encrypt, encrypt!" 
were seen as kooks, but we now know beyond a shadow of a doubt that 
there are a legion of organizations, both public and private sector, 
that are collecting every piece of data about every person that they 
can. We also know that their reach is way farther than was imagined, and 
it's probably actually farther than what we know now.

So the question isn't, "Why encrypt?" the question is, why on earth 
wouldn't you want to?

And Jason, you missed a threat model, which is users who want to bypass 
their ISP's resolver.

I agree that encrypting from the CMTS to the local resolver isn't that 
valuable, since (unless I'm missing something) the ISP is the only one 
that can see that traffic, and they'll be able to log/manipulate the 
resolver already. So it's unlikely that an ISP would deploy DOH or DOT 
in the first place, so the idea of a DHCP option to support it isn't 
necessarily relevant in that environment. That doesn't mean it's not 
relevant elsewhere.

Doug

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 13:07:37 -0400

I went over this in some detail a while back, but to recap, the point of
something like DoH or DoT is to protect the client from eavesdropping.
 There are three senses in which this can be useful.

   - First, that there is a trust relationship between the client and the
   server, which is validated using PKI.   This trust relationship prevents
   anyone other than the trusted server from seeing the client's queries.
   - Second, that the client just wants protection from eavesdropping on
   the local wire, and doesn't actually trust the network operator, but uses
   the provided DoT or DoH information because it protects from third party
   eavesdroppers.
   - Third, the client has a trust relationship with the provider because
   the provider of the client software configured it that way.

What's important about this is that the first and second types of trust
relationships are mutually exclusive.   If you have the first, that
precludes the second.   You have to pick which one you want.   The third is
essentially a special case of the first, but I mention it because people
tend to describe them as if they are different.

So if you are relying on the first kind of trust relationship, then you
can't use DHCP, because you have no trust relationship with DHCP.  If you
are relying on the second trust relationship, you are assuming that the
network operator is competent; otherwise a third party can still eavesdrop
on your traffic by providing DHCP service on the local wire.   Paul and
Bert have talked about why the third kind of trust relationship is
problematic.

So you have trust relationship one, which has the problems Paul talks
about.   You have trust relationship two, which has a different set of
problems, and is incompatible with trust relationship one.   And you have
trust relationship three, which is a special case of trust relationship one.

The DHCP solution is compatible only with trust relationship two.   So if
the IETF were to recommend this way of configuring DoH and DoT, we would
essentially be throwing away the privacy benefits of DoH and DoT (assuming
that such benefits exist).   Paul states this as if it's just obvious that
when you are connected to a particular network, you have to follow the
rules of that network, but this is kind of a special-case argument: Paul
runs his network that way, and he gave some examples of other networks that
are run that way, but there are also lots of networks that aren't run that
way, and as an end user who owns his device and does not live in a country
that censors the Internet, I am not willing to have the internet censorship
case be the default case.   If a device were to treat that as the default
case, I would not want to use that device.

I will freely admit that this is not clear-cut, but that's really my
point.   I believe that it is wrong to advance a DHCP-based solution
without consensus that we prefer the second trust model, and I don't think
such a consensus is attainable.   Pursuing a DHCP-based solution without
that consensus is simply a way of bypassing the consensus process, in the
sense of deciding that there is no need to get consensus on which trust
model we prefer before choosing a trust model.

On Sun, Aug 19, 2018 at 12:43 PM, Doug Barton <[email-masked]> wrote:

> protecting the user from by not allowing a DHCP option to use a DOH or DOT
> server?
>
> It seems to me that in the overwhelming majority of cases (near 100%) the
> user is going to get their local resolver from the DHCP server, whether
> they are on a trusted network (like work or home), or roaming at Eve's
> Coffee Shop.
>
> doesn't understand how any of this stuff works, and therefore has implicit
> "trust" regarding the local network and the settings from the DHCP server.
>
> Given that (and feel free to tell me if I've missed something), what harm
> can come to the user if the resolver that they are already trusting can
> also be accessed over DOH or DOT?
>
> Doug
>
>

---

From: Craig Finseth <[email-masked]>
Date: Sun, 19 Aug 2018 12:20:53 -0500

Or, you have malware trying to bypass DNS checks.

Craig Finseth 

> On Aug 19, 2018, at 11:43, Doug Barton <[email-masked]> wrote:
> 
>> The thing is that most devices don't connect to just one network.   So while your devices on your network can certainly trust port 853 on your network, when they roam to other networks, they have no reason to trust it.   If you have devices that never roam to other networks, that's fine, but we have to design for the more general case.   There's no way with DHCP for the device to tell that it's connected to a particular network, other than matching IP addresses, which isn't a great idea.
> 
> Ted,
> 
> I'd like to turn your question back to you. What threat model are you protecting the user from by not allowing a DHCP option to use a DOH or DOT server?
> 
> It seems to me that in the overwhelming majority of cases (near 100%) the user is going to get their local resolver from the DHCP server, whether they are on a trusted network (like work or home), or roaming at Eve's Coffee Shop.
> 
> So either you have a sophisticated user who has preconfigured their own resolver and ignores the DHCP setting, or you have the typical user who doesn't understand how any of this stuff works, and therefore has implicit "trust" regarding the local network and the settings from the DHCP server.
> 
> Given that (and feel free to tell me if I've missed something), what harm can come to the user if the resolver that they are already trusting can also be accessed over DOH or DOT?
> 
> Doug
>

---

From: Paul Vixie <[email-masked]>
Date: Sun, 19 Aug 2018 10:29:33 -0700

Ted Lemon wrote:
...
> without consensus that we prefer the second trust model, and I don't
> think such a consensus is attainable.   Pursuing a DHCP-based solution
> without that consensus is simply a way of bypassing the consensus
> process, in the sense of deciding that there is no need to get consensus
> on which trust model we prefer before choosing a trust model.

there hasn't been, is not, and won't be, consensus on a trust model. as 
in your enumeration, some trust models are incompatible with others and 
cannot be in any way mixed. i think the protocols should support what 
people are trying to do, and that means no single overarching trust model.

-- 
P Vixie

---

From: "Livingood, Jason" <[email-masked]>
Date: Sun, 19 Aug 2018 18:01:29 +0000

> Personally I see securing the path from the stub to the resolver as a 
    good step in the ultimate goal of encrypting all of the things. :) 

[JL] No disagreement here. I think the issue may be more to do with choice over the resolver (how it gets assigned). To date on the Internet that's all been down to local policy or user choice to override those policies, but now it seems like the alternative proposal may look like a centralized / top-down policy model. That's probably more the friction point than the encryption itself. 

    wouldn't you want to?
   
[JL] Again, I agree. I think it boils down quite simply to how the resolver is assigned, and whether user choice or local policy can override that assignment, and perhaps as well what data is passed from recursive to authority (e.g. EDNS-CS).
 
> So it's unlikely that an ISP would deploy DOH or DOT 
    in the first place, 

[JL] I would not make that assumption; it could well be ISPs would be natural early adopters given the chance to do so.

> so the idea of a DHCP option to support it isn't 

[JL] It seems silly not to allow for a way for DHCP assignment of DOH/DOT servers. Surely it must be the case this is possible? If the network wants to assign them, then so be it IMO. The user can always ignore and override that optionally - as they do today with various public recursive resolvers.

---

From: Tom Pusateri <[email-masked]>
Date: Sun, 19 Aug 2018 14:35:16 -0400

> On Aug 19, 2018, at 9:29 AM, Livingood, Jason <[email-masked]> wrote:
> 

In the DRIU BOF, I mentioned establishing a reputation service for public DNS resolvers. With a JSON interface, this could lead to users conveying some trust of a public service or more likely, the inverse of trust for operating systems or stub resolvers to whitelist/blacklist public DNS resolvers.

I tried to summarize it here:

https://dnsdisco.com/reputation-post.html <https://dnsdisco.com/reputation-post.html>

Or you could go listen to the proceedings of the DRIU BOF.

Thanks,
Tom

---

From: Marek Vavruša <[email-masked]>
Date: Sun, 19 Aug 2018 11:46:30 -0700

Interesting. This approach is similar to the lists curated by Frank
and people from dnscrypt-proxy: https://dnscrypt.info/public-servers

Assuming that separating protocol change from trust model change is a
no-go, then the trust would need to go both ways - the network
operator would need to push the list of resolvers that she considers
trusted, and the client would crosscheck that list to its provisioned
configuration (or list downloaded from a public service such as this
etc.). This is conceptually similar to NPN/ALPN.

Marek

On Sun, Aug 19, 2018 at 11:35 AM, Tom Pusateri <[email-masked]> wrote:
> On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert"
> <[email-masked] on behalf of [email-masked]> wrote:
> concerns lie. Thus, the issue is likely less DoH itself but rather how it is
> likely to be deployed.
>
> share concern, given the apparent deployment model, around what may break in
> enterprise networks, malware detection & remediation, walled garden portals
> during service provisioning, parental controls, and the impacts of
> In the DRIU BOF, I mentioned establishing a reputation service for public
> DNS resolvers. With a JSON interface, this could lead to users conveying
> some trust of a public service or more likely, the inverse of trust for
> operating systems or stub resolvers to whitelist/blacklist public DNS
> resolvers.
>
> https://dnsdisco.com/reputation-post.html
>

---

From: [email-masked]
Date: Sun, 19 Aug 2018 20:48:41 +0200 (CEST)

> that such benefits exist).

I don't believe people are saying that the IETF should *recommend*
this way of configuring DoH and DoT - they're saying the DHCP option
should be *available*.

Are you saying that all DHCP options introduced so far have been the
IETF recommended way of configuring things?

Are you saying that no new DHCP option can be made available unless
the IETF recommends this way of configuring things?

Both of these sound equally unreasonable/unlikely to me...

Steinar Haug, AS2116

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 15:28:30 -0400

I am indeed saying that when the IETF publishes a standards track document
with an applicability statement, the IETF is recommending that, where
applicable, the specification be used.

The problem with not deciding on the trust model is that it would be
impossible to write a clear applicability statement, and hence the protocol
would be implicitly applicable in all cases.   When you are designing a
protocol with very serious and significant trust implications, this is a
really bad idea.

Think about DHCP providing an SMTP server address.   Does that make sense?
 What is the trust model?   The IETF does indeed recommend this for IPv4,
but we didn't do it for IPv6 because we'd realized by the time we did RFC
3315 that not every single thing you can in principle configure with DHCP
should be configured with DHCP.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 15:36:04 -0400

That may indeed be correct.   If it is correct, then the next step would be
to try to design a trust model that we can agree on, that addresses both
use cases rather than requiring us to choose one or the other.   E.g., we
could say that if you are Chinese, then your device is required to trust
the GFWoC; if you are not, and you never go to China, your device should
not trust it.  If you aren't Chinese but you travel to China, you should
probably be asked to make a policy decision.   And now when the network
operator hands you a DoH or DoT server, you should be able to validate what
you've been handed.   Am I willing to trust Paul Vixie's network?   Then I
can configure that, and then when I am on Paul's network and his network
hands me a pointer to his DoH server, I'll use that.   When I'm not on his
network, I won't.   Right?

On Sun, Aug 19, 2018 at 2:46 PM, Marek Vavruša <[email-masked]>
wrote:

> > On Aug 19, 2018, at 9:29 AM, Livingood, Jason <

---

From: Paul Ebersman <[email-masked]>
Date: Sun, 19 Aug 2018 14:04:30 -0600

mellon> Think about DHCP providing an SMTP server address. Does that
mellon> make sense?

That doesn't. But DHCP already hands out DNS servers. You are already
trusting the DHCP server to give you default gateway and DNS server (or
you are choosing not to use DHCP).

Take the use case of coffee house or wireless hotspot. I think that it
would be an improvement of privacy to not allow anyone there to sniff
DNS packets because the owner of the network uses DOH for their
recursive resolver. I'm already trusting the network for default gateway
and most users would trust the DNS servers handed via DHCP. So no huge
new leap of trust and improved privacy. Seems like a win.

Why not allow network operators that option via a new DHCP option? You
don't have to use it but it would be a good choice for some.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 17:01:59 -0400

Right, that's the second trust model.   It's incompatible with the first
trust model.   Did you see the message earlier to day where I described
these trust models?

---

From: Doug Barton <[email-masked]>
Date: Sun, 19 Aug 2018 15:06:51 -0700

I agree with Steinar's sensibilities on this, FWIW.

Ted, you've restated your thesis several times now, but what I haven't 
seen is an answer to my question, so let me pose it a different way.

How is a user that relies on the DHCP server's DOH or DOT resolving name 
server instructions worse off than one who relies on the DHCP server's 
ordinary resolving name server instruction?

Also, we're not talking about introducing a new service here, we're 
talking about a configuration detail for a service that not only already 
exists, but is critical to get any real work done once you're on the 
network.

Doug

On 08/19/2018 12:28 PM, Ted Lemon wrote:
> I am indeed saying that when the IETF publishes a standards track 
> document with an applicability statement, the IETF is recommending that, 
> where applicable, the specification be used.
> 
> impossible to write a clear applicability statement, and hence the 
> protocol would be implicitly applicable in all cases.   When you are 
> designing a protocol with very serious and significant trust 
> implications, this is a really bad idea.
> 
> Think about DHCP providing an SMTP server address.   Does that make 
> sense?   What is the trust model?   The IETF does indeed recommend this 
> for IPv4, but we didn't do it for IPv6 because we'd realized by the time 
> we did RFC 3315 that not every single thing you can in principle 
> configure with DHCP should be configured with DHCP.
> 
> 
> On Sun, Aug 19, 2018 at 2:48 PM, <[email-masked] 
> <mailto:[email-masked]>> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 19:46:23 -0400

A user who relies on the dhcp server for dns server info is no worse off.
The problem is that if your host lets the dhcp server override the DoT or
DoH configuration you entered manually, you are a lot worse off. So you
have to specify how you’re going to handle this. I’m not saying don’t do
it. I’m saying figure out how to specify it so that either that is the only
use case, or the other is the only use case, or the implementor knows how
to make the right thing happen for both cases. Don’t just pretend there’s
no conflict.

---

From: manu tman <[email-masked]>
Date: Sun, 19 Aug 2018 16:57:10 -0700

On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon <[email-masked]> wrote:

> DoH configuration you entered manually, you are a lot worse off.
>

This seems to be a static vs dynamic setup. Either you use dynamic and you
will happily accept what you get from DHCP and possibly upgrade to
(HTTP|TL)S or you have set your resolvers statically and you are already
ignoring the nameservers provided by the DHCP server.
If you do not accept the servers provided by DHCP, there is no reason you
would accept extra attributes for those same snameservers.
Manu

> So you have to specify how you’re going to handle this. I’m not saying
> don’t do it. I’m saying figure out how to specify it so that either that is
> the only use case, or the other is the only use case, or the implementor
> knows how to make the right thing happen for both cases. Don’t just pretend
> there’s no conflict.
>

---

From: Paul Vixie <[email-masked]>
Date: Sun, 19 Aug 2018 17:10:52 -0700

i think a good modern stub should have several settings that are missing 
in today's stable of internet endpoints.

"these are my preferred servers, even when dhcp tells me otherwise"

"if there's a tcp/853 trust path available, and it works, prefer it"

"if my preferred servers can't be reached i do/don't want to follow dhcp"

"if dhcp doesn't give me working servers, try these global ones instead"

the lack of these knobs today should not inform our debate as to whether 
to add dhcp elements to support tcp/853. rather, they are a separate 
problem -- just as dhcp authentication is a separate problem.

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 20:12:51 -0400

Okay. How are you going to write the applicability statement?

---

From: Doug Barton <[email-masked]>
Date: Sun, 19 Aug 2018 17:28:11 -0700

On 08/19/2018 04:57 PM, manu tman wrote:
> 
> 
> On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>     A user who relies on the dhcp server for dns server info is no worse
>     off. The problem is that if your host lets the dhcp server override
>     the DoT or DoH configuration you entered manually, you are a lot
>     worse off. 
> 
> 
> 
> This seems to be a static vs dynamic setup. Either you use dynamic and 
> you will happily accept what you get from DHCP and possibly upgrade to 
> If you do not accept the servers provided by DHCP, there is no reason 
> you would accept extra attributes for those same snameservers.
> Manu

Yes, those are my thoughts precisely.

I don't see a risk model where a user configures DOH or DOT servers 
explicitly, but does not disable DHCP configuration for DNS. Am I 
missing something?

---

From: Ted Lemon <[email-masked]>
Date: Sun, 19 Aug 2018 22:17:14 -0400

No, I think maybe I haven't been communicating as well as I should.   What
I have been saying is that we need to decide what our threat model is, so
that we can figure out what to recommend.   What you are saying is "we
should recommend this."   What you are proposing to recommend has a
perfectly valid threat model associated with it.   I'm just saying write
that up, don't just leave it unstated.   Let's get clarity on it and decide
that we're okay with it, or not, before we write a standard based on it.
 I don't think this needs to be a heavy-weight process—I'm just objecting
to the handwaving.   And to be clear, the model that Paul has been
advocating actually is not what you just said—it's a different, also valid,
threat model.   The problem with Paul's model is that it assumes a user who
is able to reason clearly about threat models; I don't think we can do
that, and I would object to a spec that was based on that threat model.   I
think we need to do that work, and not leave it to the user.   We've all
seen what happens when you demand that users be security experts.

On Sun, Aug 19, 2018 at 8:28 PM, Doug Barton <[email-masked]> wrote:

>> On Sun, Aug 19, 2018 at 4:46 PM Ted Lemon <[email-masked] <mailto:
>> [email-masked]>> wrote:
>>
> explicitly, but does not disable DHCP configuration for DNS. Am I missing
> something?
>
>

---

From: Doug Barton <[email-masked]>
Date: Sun, 19 Aug 2018 22:53:48 -0700

Resorting to in-line responses to reduce the amount of talking past each 
other.

On 08/19/2018 07:17 PM, Ted Lemon wrote:
> No, I think maybe I haven't been communicating as well as I should.  
>   What I have been saying is that we need to decide what our threat 
> model is,

You've been very clear on your numerous repetitions that this is your 
perspective. I and others have quite clearly disagreed with that. Please 
don't mistake lack of agreement with lack of clarity. I understand your 
argument, I just don't agree with it.

> so that we can figure out what to recommend.   What you are 
> saying is "we should recommend this." 

No, I'm definitely NOT saying that. I and others have expressed surprise 
that you feel that the existence of a DHCP option constitutes an 
endorsement. I've been in the business over 20 years, and have never 
heard this line of reasoning, for example.

>  What you are proposing to 
> recommend has a perfectly valid threat model associated with it.   I'm 
> just saying write that up, don't just leave it unstated.   Let's get 
> clarity on it and decide that we're okay with it, or not, before we 
> write a standard based on it.   I don't think this needs to be a 
> heavy-weight process—I'm just objecting to the handwaving.   And to be 
> clear, the model that Paul has been advocating actually is not what you 
> just said—it's a different, also valid, threat model.   The problem with 
> Paul's model is that it assumes a user who is able to reason clearly 
> about threat models; I don't think we can do that, and I would object to 
> a spec that was based on that threat model.   I think we need to do that 
> work, and not leave it to the user.   We've all seen what happens when 
> you demand that users be security experts.

I think Paul's threat model and mine have more in common than you 
imagine, but I'll leave that aside. What confuses me is the idea that a 
given option can only be deployed to address one threat model. Clearly, 
for any draft the security section needs to weigh the pros and cons of 
the approach.

What it seems like we do agree on is that there is no additional risk to 
the user who would have been relying on the unencrypted resolver anyway 
to rely on an encrypted one.

While your three security models have distinctions to a person who is 
knowledgeable about such things, the only time they matter to your 
normal, non-security-aware user is when they intentionally configure a 
resolver (DOH/DOT or not). If they do this, they are taken out of the 
realm of DHCP resolver options entirely.

Doug

> On Sun, Aug 19, 2018 at 8:28 PM, Doug Barton <[email-masked] 
> <mailto:[email-masked]>> wrote:
> 
>         <mailto:[email-masked]> <mailto:[email-masked]
>         <mailto:[email-masked]>>> wrote:
> 
>         This seems to be a static vs dynamic setup. Either you use
>         dynamic and you will happily accept what you get from DHCP and
>         possibly upgrade to (HTTP|TL)S or you have set your resolvers
>         statically and you are already ignoring the nameservers provided
>         by the DHCP server.
>         If you do not accept the servers provided by DHCP, there is no
>         reason you would accept extra attributes for those same
>         snameservers.
>         Manu
> 
> 
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/dnsop>
> 
>

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 20 Aug 2018 13:48:38 +0200 (CEST)

> Il 19 agosto 2018 alle 19.02 Doug Barton <[email-masked]> ha scritto:
> And Jason, you missed a threat model, which is users who want to bypass their ISP's resolver.

I think that there should be a lot more attention to this "use case" in this discussion. It seems to me that the designers of DoH have in their minds a romantic picture of the dissident in some authoritarian country trying to escape censorship and save her own life, so that being able to bypass the local ISP, obviously run by evil government cronies, would be a good thing. 

However, in most of the world, the reality is that the biggest motivation for people to try bypassing the ISP's resolver is to access illegal Web content that has been filtered out at the DNS level, such as unauthorized gambling websites, illegal pornography, "free" football live streams (which are usually full of malware), etc. - not to mention bots trying to contact their command and control server without incurring into RPZ-based filtering.

If I accepted Ted Lemon's point that publishing a proposed standard (like DoH) implies active endorsement by the IETF, I would wonder why the IETF is actively endorsing a standard that will make this much easier.

> necessarily relevant in that environment. That doesn't mean it's not 

Well, if I were an ISP, I'd rush to deploy DoH on my consumer resolver so to deprive the browser makers of the excuse "we are redirecting by default your DNS traffic to us because we encrypt it and your ISP does not". I agree that technically speaking there is not a lot of need for this, but DoH (more precisely: the upcoming deployment of DoH in the browsers) is mostly a business and marketing issue, not a technical one.

Regards,
-- 

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

---

From: Joe Abley <[email-masked]>
Date: Mon, 20 Aug 2018 11:41:16 -0400

> However, in most of the world, the reality is that the biggest motivation for people to try bypassing the ISP's resolver is to access illegal Web content that has been filtered out at the DNS level…

These are the same use-case, just viewed with different bias.

Joe

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 08:49:54 -0700

Joe Abley wrote:
...
> These are the same use-case, just viewed with different bias.

so, DoH's use cases all involve either violating the law, or violating 
the network operator's security policy? egads, i hope not. the ietf 
can't be seen backing something that has _no_ legitimate purpose.

-- 
P Vixie

---

From: Joe Abley <[email-masked]>
Date: Mon, 20 Aug 2018 11:54:14 -0400

On Aug 20, 2018, at 11:49, Paul Vixie <[email-masked]> wrote:

> so, DoH's use cases all involve either violating the law, or violating the network operator's security policy?

I don't know how you managed to read that into what I wrote. I was just saying that those two particular use-cases were the same.

Joe

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 11:55:02 -0400

Paul, it's really not helpful to do this kind of reductio ad absurdum.

You are assuming that all networks operators have a security policy which
they have a right to enforce on the end user.   In some cases this is
true.   In most cases it is false.   E.g., the network to which I am
currently connected has no such right of enforcement.   It would be
*catastrophic* if it did, because I'm the paying customer, and supposedly
this is a country in which freedom of speech is guaranteed.   I am entirely
within my rights to use DoH whether the network operator likes it or not.
 It is not illegal for me to do so, and if I did so, it would not be so
that I could violate the law—it would be so that I could protect my privacy
and avoid DNS spoofing that returns forged answers, which I consider to be
a security threat, and which I am fairly certain my network operator does.

It is certainly true that in some cases, someone using DoH would be
violating a network operator policy that is enforceable, or would be
violating the law.   But that is by no means the most common case, and it
does you no credit to pretend otherwise.

On Mon, Aug 20, 2018 at 11:49 AM, Paul Vixie <[email-masked]> wrote:

> ....
> so, DoH's use cases all involve either violating the law, or violating the
> network operator's security policy? egads, i hope not. the ietf can't be
> seen backing something that has _no_ legitimate purpose.
>
> --
> P Vixie
>
>

---

From: Paul Wouters <[email-masked]>
Date: Mon, 20 Aug 2018 12:02:19 -0400 (EDT)

On Mon, 20 Aug 2018, Paul Vixie wrote:

> network operator's security policy? egads, i hope not. the ietf can't be seen 
> backing something that has _no_ legitimate purpose.

None of the hotels, coffeeshops or prepaid SIM cards I buy disallow me
either by corporate policy or by local law to not share my DNS traffic
with them.

Paul

---

From: Vittorio Bertola <[email-masked]>
Date: Mon, 20 Aug 2018 18:41:53 +0200 (CEST)

> Il 20 agosto 2018 alle 17.55 Ted Lemon <[email-masked]> ha scritto:  
> 
>  I am entirely within my rights to use DoH whether the network operator likes it or not.   It is not illegal for me to do so, and if I did so, it would not be so that I could violate the law—it would be so that I could protect my privacy and avoid DNS spoofing that returns forged answers, which I consider to be a security threat, and which I am fairly certain my network operator does.
>  
> It is certainly true that in some cases, someone using DoH would be violating a network operator policy that is enforceable, or would be violating the law.   But that is by no means the most common case, and it does you no credit to pretend otherwise.

Can you substantiate this statement with data / details? Because I only know cases in which:
a) ISPs filter out content on behalf of the local government due to legal requirements/court orders;
b) ISPs filter out content on request by the user, e.g. for parental control; in the UK, ISPs are actually required by law to provide this service to the user, that can then decide whether to activate it or not and even what to filter out;
c) ISPs filter out threats such as botnets, compromised websites distributing malware, etc - this does not entail any freedom of speech consideration and contributes to everyone's security.

In many European countries network operators are selling b)+c) (see for example https://securenet.vodafone.com/ ) and people are actively buying the service, so they explicitly want this kind of filtering (and will not be able to continue getting it if their browser redirects their DNS queries somewhere else); and if you do not want it, you just don't buy it. As for a), possibly users do not want it, but it is still mandated by law.
 
So I cannot immediately recall cases in which a network operator in Europe is filtering out things that a user wants and can lawfully access. But you mention that your network operator is spoofing the DNS and stifling your freedom of expression, so I guess it is censoring legitimate websites - this is bad, of course, but can you tell me which operator, and which websites? It would help my understanding of your use case.

Finally, note that *in your country* it may be your right to use DoH to tamper with what your network operator is doing, but this may not be true in other countries. In fact, deploying any technology that circumvents security measures that network operators are required to implement by law might be illegal in itself.

In the end, the DNS is a very complex policy subject (see the mess that ICANN is) with lots of stakeholders and conflicting views, and IMHO such a deep change in its architecture and "ecosystem" would require much more caution and a much broader discussion going well beyond the IETF.

Regards,
--

---

From: Tony Finch <[email-masked]>
Date: Mon, 20 Aug 2018 17:42:10 +0100

> https://github.com/vavrusa/draft-dhcp-dprive/blob/master/draft-dhcp-dprive.txt

This is interesting to me because I want to support DoTH on my campus
resolvers.

Regarding DoT, it seems to me that a super simple way for the client to
be able to authenticate the server would be to include the server's IP
address(es) in the subjectAltName field. This wouldn't require a DHCP
extension, and nicely supports opportunistic updgrade. I'm afraid I wasn't
paying attention when RFC 8310 was being prepared so I don't know why it
excludes iPAddress authentication.

Regarding DoH, the DHCP option ought to include a URI template (there
isn't a .well-known for DoH). I plan to set up my servers so that
misdirected attempts to get web pages from the DoH server are redirected
to the relevant documentation; that's much easier if the DoH endpoint
isn't at the server root.

A URI template usually implies the need for DNS queries to resolve the
server name (unless it's an address literal). Would it be plausible to
allow the client to assume that the DoH server IP addresses are the same
as the DNS server addresses, so it can skip the lookup? I guess that would
be too annoying for operators that want their DoH servers to be separate
from their normal DNS resolvers, so maybe it's a bad idea :-)

Tony.

(PS. DoTH is clearly what happens if someone suggests "DoNT" but we do it anyway.)

-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
fight poverty, oppression, hunger, ignorance, disease, and aggression

---

From: manu tman <[email-masked]>
Date: Mon, 20 Aug 2018 09:50:59 -0700

I am going to echo my original comment on the draft as it may have been
lost in this long thread and it will make sense to keep this close to
related convo.

```
```

Manu

On Mon, Aug 20, 2018 at 9:42 AM Tony Finch <[email-masked]> wrote:

> fight poverty, oppression, hunger, ignorance, disease, and
> aggression_______________________________________________
> DNSOP mailing list
> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 12:51:41 -0400

> requirements/court orders;
Yes, although in many cases they are required by law to do it, but I am not
required by law to accept it—I can quite legally bypass this feature if I
want to.

> b) ISPs filter out content on request by the user, e.g. for parental
> control; in the UK, ISPs are actually required by law to provide this
> service to the user, that can then decide whether to activate it or not and
> even what to filter out;
>

Yes, and in that case wouldn't it be nice to be able to know that you're
actually talking to the right resolver?   You can't do that with DHCP.

> c) ISPs filter out threats such as botnets, compromised websites
> distributing malware, etc - this does not entail any freedom of speech
> consideration and contributes to everyone's security.
>

Same question.

> In many European countries network operators are selling b)+c) (see for
> example https://securenet.vodafone.com/ ) and people are actively buying
> the service, so they explicitly want this kind of filtering (and will not
> be able to continue getting it if their browser redirects their DNS queries
> somewhere else); and if you do not want it, you just don't buy it. As for
> a), possibly users do not want it, but it is still mandated by law.
>

Yup, absolutely.   I used to work for Nominum—we made a product that did
this, and a lot of people bought it, and I think they were wise to do so.

> So I cannot immediately recall cases in which a network operator in Europe
> is filtering out things that a user wants and can lawfully access. But you
> mention that your network operator is spoofing the DNS and stifling your
> freedom of expression, so I guess it is censoring legitimate websites -
> this is bad, of course, but can you tell me which operator, and which
> websites? It would help my understanding of your use case.
>

No, it's not bad.   It's the service they offer, and it's fine that they
offer it.   I think it's the right default.   It's also fine that I choose
to bypass it.

> Finally, note that *in your country* it may be your right to use DoH to
> tamper with what your network operator is doing, but this may not be true
> in other countries. In fact, deploying any technology that circumvents
> security measures that network operators are required to implement by law
> might be illegal in itself.
>

Yes, and if we come up with a solution that allows both situations to be
securely communicated to the end user device, and allows the end user to
make an informed decision about whether or not to use the service with
these restrictions in place, I'm okay with that, and I think it's
appropriate for the IETF to do it.   What I am arguing is that we should
actually describe how to do that, and not just hack together a solution
without thinking about that.

> In the end, the DNS is a very complex policy subject (see the mess that
> ICANN is) with lots of stakeholders and conflicting views, and IMHO such a
> deep change in its architecture and "ecosystem" would require much more
> caution and a much broader discussion going well beyond the IETF.

I believe that I too have been arguing for caution.   Perhaps we disagree
on what the outcome of that cautious approach would be, but we both seem to
agree that it's worth thinking about carefully.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 09:57:51 -0700

>> Il 20 agosto 2018 alle 17.55 Ted Lemon<[email-masked]>  ha
>> scritto:
>>
>> I am entirely within my rights to use DoH whether the network
>> operator likes it or not.

so, their network, but not their rules? when spammers used to tell me 
that sending spam wasn't illegal and i had to accept it, i blackholed 
them and said, my network, my rules. who has what rights, and why?

>> violating a network operator policy that is enforceable, or would
>> be violating the law.   But that is by no means the most common
>> case, and it does you no credit to pretend otherwise.

some references i've seen go by in this thread indicate that the DoH 
team wants its protocol to be unblockable, and hopes that RDNS DOH 
providers will co-locate their DOH endpoints with other valuable 
content, "so that network operators will think twice about blocking it."

if there are use cases beyond violating the law and violating network 
operator security policy, then they are obviously secondary, but do 
tell-- what do you think those might be?

i also block tor endpoints. because, my network, my rules. if it's going 
to be my network but mozilla's or cloudflare's rules, then this 
conversation is going to travel very differently, because i'll still be 
paying for it, but it won't be _my_ network any more. would that sit 
well with you? it wouldn't with me.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 13:06:41 -0400

On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie <[email-masked]> wrote:

> so, their network, but not their rules? when spammers used to tell me that
> sending spam wasn't illegal and i had to accept it, i blackholed them and
> said, my network, my rules. who has what rights, and why?

Paul, take a deep breath.   I'm paying for my network service.   My ISP
does not require me to use their DNS resolvers.   U.S. law does not require
me to use their DNS resolvers.   So yes, I am perfectly within my rights to
not use their DNS resolvers, but the reason is not "their network, my
rules."   It is that there's no rule against doing it.

> some references i've seen go by in this thread indicate that the DoH team
> wants its protocol to be unblockable, and hopes that RDNS DOH providers
> will co-locate their DOH endpoints with other valuable content, "so that
> network operators will think twice about blocking it."
>

I think the DoH team is not quite as cohesive as you think it is, but yes,
that is one implication of the use of DoH.  If you find it problematic,
then you need to get your end users to proxy all their HTTPS traffic
through your HTTPS proxy.   This will be really obvious to them, so you
won't be able to do it without their agreement.   This is by design.   This
situation has existed since HTTPS has existed—it's not something that DoH
invented.   You've always been able to use HTTPS to bypass firewalls; this
has good uses and bad.   Tough luck—see Figure One.  :)

> operator security policy, then they are obviously secondary, but do tell--
> what do you think those might be?
>

Preventing user behavior tracking seems like a pretty valid use case.

> paying for it, but it won't be _my_ network any more. would that sit well
> with you? it wouldn't with me.

If you think that Mozilla isn't trustworthy, don't use Firefox.   It's all
about trust.   It's naive to think that you aren't going to have to trust
someone; thinking about trust models is no longer optional for network
operators.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 10:53:30 -0700

Ted Lemon wrote:
> On Mon, Aug 20, 2018 at 12:57 PM, Paul Vixie <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     so, their network, but not their rules? when spammers used to tell
>     me that sending spam wasn't illegal and i had to accept it, i
>     blackholed them and said, my network, my rules. who has what rights,
>     and why?
>
> Paul, take a deep breath.   I'm paying for my network service.

if the plural of anecdote was data, i'd counter by saying, my family and 
my employees and my visitors do not pay for my network service. but that 
way lies madness. your network, your rules. if you're paying for it then 
you should make the rules. i pay for mine; i make my own rules.

>> team wants its protocol to be unblockable, ...
>
> I think the DoH team is not quite as cohesive as you think it is,
> but yes, that is one implication of the use of DoH. If you find it
> problematic, then you need to get your end users to proxy all their
> HTTPS traffic through your HTTPS proxy. This will be really obvious
> to them, so you won't be able to do it without their agreement.

indeed, DoT was designed to solve this problem -- it can't be 
intercepted or blocked without the user become aware of it. but it's 
designed to be blockable by network operators who don't want it to be 
used. that's better engineering, because it rams nothing down any throat.

> This is by design. This situation has existed since HTTPS has
> existed—it's not something that DoH invented. You've always been able
> to use HTTPS to bypass firewalls; this has good uses and bad. Tough
> luck—see Figure One. :)

see also my own prior work in this area:

https://github.com/BII-Lab/DNSoverHTTP

the difference there was, it's ad hoc, intended to solve point problems 
for individuals, and it would be very easy to block if it caused new or 
worse problems for the coffee shop or hotel room owner.

DOH is designed to be hard to block and to become ubiquitous. that's a 
problem that no amount of gaslighting will reduce the relevance of.

> Preventing user behavior tracking seems like a pretty valid use case.

it would be, if it was cheap to block. that is, on my network, under my 
rules, user behaviour tracking may be my policy. a user who wants to 
avoid that tracking should ask for non-tracking. if they won't ask, or 
if i say no, then the default should be non-functionality.

the DOH people are trying to ram something down the throats of network 
operators worldwide, and i'm gagging on it. a deep breath won't help.

>> i also block tor endpoints. because, my network, my rules. if it's
>> going to be my network but mozilla's or cloudflare's rules, then this
>> conversation is going to travel very differently, because i'll still
>> be paying for it, but it won't be _my_ network any more. would that
>> sit well with you? it wouldn't with me.
>
> If you think that Mozilla isn't trustworthy, don't use Firefox. It's
> all about trust. It's naive to think that you aren't going to have
> to trust someone; thinking about trust models is no longer optional
> for network operators.

this has nothing to do with trusting mozilla, although in this case, 
they are giving me reasons to treat them as a hostile opponent.

this has nothing to do with what i use. for me it's about employees, 
family members, and visitors. for turkey and china and others, it's 
about national law. the ietf has not been knowingly and deliberately 
hostile to local network policy before now. this is a sea change. it 
will not end here, and it will escalate.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 14:03:15 -0400

On Mon, Aug 20, 2018 at 1:53 PM, Paul Vixie <[email-masked]> wrote:
> rules, user behavior tracking may be my policy. a user who wants to avoid
> that tracking should ask for non-tracking. if they won't ask, or if i say
> no, then the default should be non-functionality.
>

Well, the success of the HTTP Do Not Track header field certainly supports
your argument here...

> operators worldwide, and i'm gagging on it. a deep breath won't help.

this has nothing to do with what i use. for me it's about employees, family
> members, and visitors. for turkey and china and others, it's about national
> law. the ietf has not been knowingly and deliberately hostile to local
> network policy before now. this is a sea change. it will not end here, and
> it will escalate.

I think HTTPS was pretty hostile to local network policy.   Indeed, there
was a big argument about that in the TLS working group over the past few
IETFs.   If you don't want people to use DoH, there's an easy solution,
which you already need to use regardless: you have to MiTM their HTTTPS
traffic.   If you don't agree that you have to MiTM their HTTPS traffic to
achieve what you want, then I think we are not arguing about the same thing.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 11:11:49 -0700

Ted Lemon wrote:
...
> I think HTTPS was pretty hostile to local network policy.   Indeed,
> there was a big argument about that in the TLS working group over the
> past few IETFs.   If you don't want people to use DoH, there's an easy
> solution, which you already need to use regardless: you have to MiTM
> their HTTTPS traffic.   If you don't agree that you have to MiTM their
> HTTPS traffic to achieve what you want, then I think we are not arguing
> about the same thing.

it used to be occasionally necessary. with DOH it will be universally 
nec'y. this will add complexity (so, cost and error rate) and increase 
surveillance. the DOH people should be told not to proceed to draft 
standard until their design accommodates the needs of network operators.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 14:15:30 -0400

I think that you are whistling past the graveyard.   If your firewall
allows HTTPS without a proxy, then everything that DoH allows is already
possible, and is probably already being done, because it's so obvious.
If you disagree with me about this (and I can think of a few reasons why
you might) then you should articulate what is possible with DoH that isn't
already possible with HTTPS.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 16:47:55 -0700

> possible, and is probably already being done, because it's so obvious.

nope. the control plane stops at my doorstep, and there is no ubiquitous 
bypass occurring. i urge you to consider my level of commitment to this 
state of affairs, and whether i'm alone, and what could happen if it's 
threatened by the DOH WG's work.

>    If you disagree with me about this (and I can think of a few reasons
> why you might) then you should articulate what is possible with DoH that
> isn't already possible with HTTPS.

done.

-- 
P Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 20 Aug 2018 20:47:55 -0400

> On Aug 20, 2018, at 12:42 PM, Tony Finch <[email-masked]> wrote:
> 

Our variant of this same idea that Willem Toorop and I presented at the DRIU BOF in Montréal has a URI for the DoH case:

But let me remind everyone that there was a lot of people agreeing with Ted in Montréal and so far, Ted appears to be standing all by himself.

Where are all the other folks that shot down this idea earlier? :)

Thanks,
Tom

---

From: "Paul Hoffman" <[email-masked]>
Date: Mon, 20 Aug 2018 18:11:10 -0700

On 20 Aug 2018, at 17:47, Tom Pusateri wrote:

> Our variant of this same idea that Willem Toorop and I presented at 
> the DRIU BOF in Montréal has a URI for the DoH case:
>
> <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00>
>
> But let me remind everyone that there was a lot of people agreeing 
> with Ted in Montréal and so far, Ted appears to be standing all by 
> himself.
>

Judging what was said at an excited mic line is always challenging. :-) 
Two issues are being conflated here:
1) a DHCP option to include a URI template
2) how the DHCP client in an OS would use that option

DHCP options are easy and cheap. However #2 was vexing. The proposal 
that an OS say "oh look, there is a DoH server, I'll use that because it 
is more secure than Do53" was what was controversial because of the 
utter lack of DHCP security. Some of the folks on the mic line disagreed 
with the assumption that, given two pieces of insecurely-acquired 
information (a Do53 address and a DoH template) that the latter would 
result with a more secure connection. A network admin can see the port 
53 traffic and see if there's crap in there; they can't see the inner 
DoH traffic.

--Paul Hoffman

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 20 Aug 2018 21:22:42 -0400

> On Aug 20, 2018, at 9:11 PM, Paul Hoffman <[email-masked]> wrote:
> 
>> https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00><https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00 <https://tools.ietf.org/html/draft-pusateri-dhc-dns-driu-00>>
>> 
> Judging what was said at an excited mic line is always challenging. :-) Two issues are being conflated here:
> DHCP options are easy and cheap. However #2 was vexing. The proposal that an OS say "oh look, there is a DoH server, I'll use that because it is more secure than Do53" was what was controversial because of the utter lack of DHCP security. Some of the folks on the mic line disagreed with the assumption that, given two pieces of insecurely-acquired information (a Do53 address and a DoH template) that the latter would result with a more secure connection. A network admin can see the port 53 traffic and see if there's crap in there; they can't see the inner DoH traffic.
> 
> --Paul Hoffman

Yes, this was one good point.

Another point I remember most clearly is that DHCP has fallen out of favor for communicating all but the most minimal network bootstrap configuration information. There was general agreement in the room that you only should use DHCP in IPv4 for address/router info and then use trusted sources for everything else. In IPv6, SLAAC generally provides this.

One more point (from the Android crowd) was that they are going to try to connect to the DNS server’s IP address using port 853 using DoT at the same time they are trying to resolve names over port 53 with UDP. If they’re able to make a DoT connection, they’ll use it. This doesn’t provide for a way to have an ADN to verify the certificate but a PTR query can give you a name to do certificate validation and/or DANE validation. So they seemed to be making the point that no DHCP extensions were necessary.

Tom

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 20 Aug 2018 19:40:30 -0600

pusateri> Another point I remember most clearly is that DHCP has fallen
pusateri> out of favor for communicating all but the most minimal
pusateri> network bootstrap configuration information. There was general
pusateri> agreement in the room that you only should use DHCP in IPv4
pusateri> for address/router info and then use trusted sources for
pusateri> everything else. In IPv6, SLAAC generally provides this.

That may be the consensus at the IETF but it's not even close the
consensus with ISPs, nor large enterprise. That seems to cover most of
the eyeball/consumer... DHCP is still how much of the world gets
connected and that hasn't changed in decades.

pusateri> One more point (from the Android crowd) was that they are
pusateri> going to try to connect to the DNS server's IP address using
pusateri> port 853 using DoT at the same time they are trying to resolve
pusateri> names over port 53 with UDP. If they're able to make a DoT
pusateri> connection, they'll use it. This doesn't provide for a way
pusateri> to have an ADN to verify the certificate but a PTR query can
pusateri> give you a name to do certificate validation and/or DANE
pusateri> validation. So they seemed to be making the point that no DHCP
pusateri> extensions were necessary.

The google/android crowd's bias against DHCP and DHCPv6 is well known
and is why android is having trouble penetrating said enterprise
market.

Getting DOH via DHCP is the same argument as TOFU and the IETF has used
TOFU.

DHCP is how hotspots, ISPs and enterprise work. Users able to understand
security risks and who read drafts from the IETF already know how to
deal with this and won't need a DHCP option. Much of the world does need
and want configure hosts/devices via DHCP.

Saying this is all broken and that we need to protect the world from
themselves by not having a DHCP option simply means that vendors will
have a slew of non-standard ways of doing it and we've helped noone.

Let's just give the option, document the security holes and risks and at
least offer much of the world a standard way of doing this if they so
choose.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 18:58:51 -0700

Tom Pusateri wrote:
...
> One more point (from the Android crowd) was that they are going to try
> to connect to the DNS server’s IP address using port 853 using DoT at
> the same time they are trying to resolve names over port 53 with UDP. If
> they’re able to make a DoT connection, they’ll use it. This doesn’t
> provide for a way to have an ADN to verify the certificate but a PTR
> query can give you a name to do certificate validation and/or DANE
> validation. So they seemed to be making the point that no DHCP
> extensions were necessary.

that's a cool hack, showing once again DoT's superiority over DoH.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 18:59:52 -0700

> connected and that hasn't changed in decades.

+1.

-- 
P Vixie

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 20 Aug 2018 19:08:17 -0700

> that's a cool hack, showing once again DoT's superiority over DoH.

This has been used to detect DoH support in dnscrypt-proxy as well.
One subtle issue with probing is that "it doesn't work" is not the
same as "it's not supported".
It can mean that port/traffic is being blocked, client is
incompatible, crypto is incompatible, etc.,
so it's difficult to distinguish whether the service is being offered
but unavailable for various reasons,
and service not being offered.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 20 Aug 2018 22:13:41 -0400

> On Aug 20, 2018, at 9:40 PM, Paul Ebersman <[email-masked]> wrote:
> 

You’re misquoting me and arguing against a point I didn’t make. There was no one saying we don’t need DHCP. There was a general agreement that DHCP should not be extended.

The DHC working group never completed the work for DHCP authentication. It’s not trustworthy enough in its current form to add more things to it.

> least offer much of the world a standard way of doing this if they so

Again, some better understanding of DoH deployment would help. I don’t know if it’s generally accepted that DoH will replace UDP/53 or DoT in the stub resolver or DoH will just end up in the browsers as a way to speed up web pages. But if DoH stays in the browser and DoT is tried and used on all DNS servers, there’s not a problem to solve.

Tom

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 19:21:12 -0700

Tom Pusateri wrote:
> ... I don’t know if it’s generally accepted that DoH will replace
> UDP/53 or DoT in the stub resolver or DoH will just end up in the
> browsers as a way to speed up web pages. But if DoH stays in the
> browser and DoT is tried and used on all DNS servers, there’s not a
> problem to solve.

if DOH is widely used by criminals, botnets, and malware to bypass 
perimeter security policy, then there will be a big problem and we will 
be solving it for many years to come, even if the browser is the only 
thing using it. browsers are where most modern vulns have occurred, and 
i expect that trend to accelerate. "because that's where the money was."

-- 
P Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 20 Aug 2018 22:25:04 -0400

> On Aug 20, 2018, at 10:21 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> Tom Pusateri wrote:
> if DOH is widely used by criminals, botnets, and malware to bypass perimeter security policy, then there will be a big problem and we will be solving it for many years to come, even if the browser is the only thing using it. browsers are where most modern vulns have occurred, and i expect that trend to accelerate. "because that's where the money was.”

I can see good use cases and bad ones.

If web servers did DNSSEC validation and only served addresses for names that were validated, I wouldn’t have a problem with that at all.

If web servers only served addresses for names within the domain of the web server, I wouldn’t have a problem with that either.

if they start serving non DNSSEC validated addresses for names outside their domain, I think they’re overreaching.

Tom

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 22:24:32 -0400

You're talking about devices over which you have no control.   So how does
it make a difference where the attack vector is on the device?   Why is
DNS-over-HTTPS worse than entire-attack-vector-over-HTTPS?

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 20 Aug 2018 20:26:27 -0600

ebersman> That may be the consensus at the IETF but it's not even close
ebersman> the consensus with ISPs, nor large enterprise. That seems to
ebersman> cover most of the eyeball/consumer... DHCP is still how much
ebersman> of the world gets connected and that hasn't changed in decades.

pusateri> You're misquoting me and arguing against a point I didn't
pusateri> make. There was no one saying we don't need DHCP. There was a
pusateri> general agreement that DHCP should not be extended.

pusateri> The DHC working group never completed the work for DHCP
pusateri> authentication. It's not trustworthy enough in its current
pusateri> form to add more things to it.

And I'd argue that this is also an IETF opinion, not the majority of the
internet. There's a reason it's still the most widespread configuration
management for devices. "Not trustworthy enough to extend" is a fine
academic opinion but doesn't hold water in the marketplace.

DHCP is no worse currently than TOFU. We trust that the OFFER packet
will be from the DHCP server we're supposed to use. Trust On First
Use. Not great but it works more than not. At least that's the argument
I kept hearing for TOFU. We actually have operational experience of
decades for DHCP and this isn't a wide spread enough problem to kill any
innovation forever because it's not perfect.

If we want the world to use what the IETF develops, we have to be able
to balance theoretical risk vs sane and widespread deployment.

If not, someone will just wind up shoving this into yet another DHCP
vendor option and every vendor will be different. That will be even less
secure.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 22:28:15 -0400

Of course, the question is, how does the consumer of that data decide what
is okay and what's not?   We can't just say that the server has to behave
correctly: someone has to enforce it.

On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri <[email-masked]> wrote:

> perimeter security policy, then there will be a big problem and we will be
> solving it for many years to come, even if the browser is the only thing
> using it. browsers are where most modern vulns have occurred, and i expect
> that trend to accelerate. "because that's where the money was.”
>
> If web servers did DNSSEC validation and only served addresses for names
> that were validated, I wouldn’t have a problem with that at all.
>
> If web servers only served addresses for names within the domain of the
> web server, I wouldn’t have a problem with that either.
>
> if they start serving non DNSSEC validated addresses for names outside
> their domain, I think they’re overreaching.
>
> Tom
>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 22:31:02 -0400

This is why we need to actually think about trust and not just handwave.
 There are a number of serious misconceptions in what you've said, Paul.

DHCP _is_ worse than TOFU, because there is an opportunity for attack at
every lease renewal, not just the first time you ever talk to a particular
DHCP server.   I actually proposed a protocol that would have worked nicely
for TOFU, but it didn't get consensus, so we don't even have TOFU-level
authenticity.

The rest of what you said is nice, but "we have to balance theoretical risk
versus sane and widespread deployment" is a statement that sounds a lot
better if we *do the math.*   If we just decide to do something without
doing the math, then we aren't really balancing anything.   We're just
deciding not to do our homework, because math is hard.

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 20 Aug 2018 22:31:48 -0400

Sure. My point was that there could be legitimate uses of DoH.

You have to move DNSSEC validation from the resolver to the client in order to really validate the answers if you can’t trust the resolver.

Tom

> On Aug 20, 2018, at 10:28 PM, Ted Lemon <[email-masked]> wrote:
> 
> Of course, the question is, how does the consumer of that data decide what is okay and what's not?   We can't just say that the server has to behave correctly: someone has to enforce it.
> 
> On Mon, Aug 20, 2018 at 10:25 PM, Tom Pusateri <[email-masked] <mailto:[email-masked]>> wrote:
> 
> 
> > On Aug 20, 2018, at 10:21 PM, Paul Vixie <[email-masked] <mailto:[email-masked]>> wrote:
> > 
> > 
> > 
> > Tom Pusateri wrote:
> https://www.ietf.org/mailman/listinfo/dnsop <https://www.ietf.org/mailman/listinfo/dnsop>
>

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 22:34:41 -0400

I agree.   We should write down the advice that we think users and
implementors of DoH need.  :)

On Mon, Aug 20, 2018 at 10:31 PM, Tom Pusateri <[email-masked]> wrote:

> You have to move DNSSEC validation from the resolver to the client in
> order to really validate the answers if you can’t trust the resolver.
>
> Tom
>
>

---

From: Tom Pusateri <[email-masked]>
Date: Mon, 20 Aug 2018 22:38:44 -0400

Come to think of it, DNSSEC validation in the stub resolver or browser is really a place DoH could shine. Instead of all the round trips required for validating up (down) the chain, the webserver could package up all those validated records and push them so the client/stub could do the validation quickly for all of the links in a page in an order that the user is most likely to need based on previous statistics and scrolling position.

Tom

> On Aug 20, 2018, at 10:31 PM, Tom Pusateri <[email-masked]> wrote:
> 
>> On Aug 20, 2018, at 10:28 PM, Ted Lemon <[email-masked] <mailto:[email-masked]>> wrote:
>>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 19:41:34 -0700

Ted Lemon wrote:
> You're talking about devices over which you have no control.   So how
> does it make a difference where the attack vector is on the device?
> Why is DNS-over-HTTPS worse than entire-attack-vector-over-HTTPS?

i'm glad you asked. operating systems, web browsers, and endpoint 
security has a pretty good handle today on data plane attacks, even if 
delivered over https. they do not however have a handle on control plane 
attacks, such as can be delivered or administered via DNS.

http://www.circleid.com/posts/20100728_taking_back_the_dns/

if ubiquitous perimeter security policy bypass via https becomes the 
norm, then far more https will have to be intercepted or blocked than is 
done today. the DOH WG is playing chicken with network operators. i wish 
they could see down the road a bit further than they do.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 19:43:55 -0700

Tom Pusateri wrote:
>
>> On Aug 20, 2018, at 10:21 PM, Paul Vixie<[email-masked]>  wrote:
>> perimeter security policy, then there will be a big problem and we
>> will be solving it for many years to come, even if the browser is
>> the only thing using it. browsers are where most modern vulns have
>> occurred, and i expect that trend to accelerate. "because that's
>> where the money was.”
>

all power tools can kill.

> If web servers did DNSSEC validation and only served addresses for
> names that were validated, I wouldn’t have a problem with that at
> all.
>
> If web servers only served addresses for names within the domain of
> the web server, I wouldn’t have a problem with that either.
>
> if they start serving non DNSSEC validated addresses for names
> outside their domain, I think they’re overreaching.

DOH's use will be indiscriminate, and will reach DNS servers who have 
web protocol front ends, who will offer full-spectrum RDNS. there will 
be no binding or relation at all between the web content servers and the 
DNS content servers who happen to use web protocols. so, please worry.

-- 
P Vixie

---

From: Paul Ebersman <[email-masked]>
Date: Mon, 20 Aug 2018 20:44:22 -0600

pusateri> Come to think of it, DNSSEC validation in the stub resolver or
pusateri> browser is really a place DoH could shine. Instead of all the
pusateri> round trips required for validating up (down) the chain, the
pusateri> webserver could package up all those validated records and
pusateri> push them so the client/stub could do the validation quickly
pusateri> for all of the links in a page in an order that the user is
pusateri> most likely to need based on previous statistics and scrolling
pusateri> position.

Agreed.

My discomfort with some current proposals where I get DNS answers to
questions I didn't ask yet would be a lot less if I had full validation
info to DNSSEC validate them. Even getting SRV and other service entry
points would be less if they're in the domain I'm already playing in and
the DNSSEC validate.

Trick with this will be getting browser support. We're still debating
why SRV is too many lookups vs CNAME at zone apex. Fingers crossed we
make progress on both.

For other apps, stubby seems like a fine way to get this in the app.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 19:47:00 -0700

Tom Pusateri wrote:
> Come to think of it, DNSSEC validation in the stub resolver or browser
> is really a place DoH could shine. Instead of all the round trips
> required for validating up (down) the chain, the webserver could package
> up all those validated records and push them so the client/stub could do
> the validation quickly for all of the links in a page in an order that
> the user is most likely to need based on previous statistics and
> scrolling position.

that's what the DOT people said, and what mr. wouters said before he 
offered the first internet draft on certificate chain responses. so, 
yes, but DOH is somewhat late to that party, and shows some ignorance.

-- 
P Vixie

---

From: Marek Vavruša <[email-masked]>
Date: Mon, 20 Aug 2018 19:47:53 -0700

> There are a number of serious misconceptions in what you've said, Paul.

I'm still not sure that IETF should define the provider of trust, as
the trust is relative.
But you're right Ted, it should definitely be at written down and formalized
if we want to move forward.

I have to compose my thoughts on this first. I'll try next weekend if I get
some of that bravery or willpower back.

> better if we do the math.   If we just decide to do something without doing
> the math, then we aren't really balancing anything.   We're just deciding
> not to do our homework, because math is hard.
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 19:51:39 -0700

Marek Vavruša wrote:
> the trust is relative. But you're right Ted, it should definitely be
> at written down andformalized if we want to move forward.
>

if you write down trust assumptions you'll be enumerating disjoint sets 
of same as actually practiced by different users and different operators 
whose reasons should be treated as valid rather than challenged.

mine is, i monitor and control the network path between my dhcp client 
and my dhcp server very much more carefully than i can monitor and 
control the network path to RDNS servers. therefore i am comfortable 
having the former introduce me to the latter. other perspectives differ.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 22:57:45 -0400

We have no privacy expectations from DNS.   We may have privacy
expectations from DoH.

On Mon, Aug 20, 2018 at 10:36 PM, Paul Ebersman <[email-masked]>
wrote:

> mellon> The rest of what you said is nice, but "we have to balance
> mellon> theoretical risk versus sane and widespread deployment" is a
> mellon> statement that sounds a lot better if we do the math.
>
> How is getting my DNS server that uses DOH worse than trusting the same
> DHCP server to give DNS servers that use UDP?
>
> I'm still waiting for a decent answer on that.
>
> If it isn't worse, we're back to "why shouldn't this be done via DHCP"?
>
> I agree that a more secure DHCP would be better. But if we're not going
> to be improving DHCP and most of the world still uses it, then it boils
> down to that question "why is DOH via DHCP worse than just DNS via
> DHCP"?
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 20 Aug 2018 20:00:03 -0700

> We have no privacy expectations from DNS.   We may have privacy

i have excellent privacy expectations from DoT, which is in fact DNS.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Mon, 20 Aug 2018 23:01:50 -0400

I think we've gone way off track here.   DoH exists, and you can't undo
that.   Maybe it was a mistake, maybe it wasn't, but that ship has sailed.
 I think you're implicitly arguing that the IETF should have done a better
job of modeling the threats before advancing the protocol, and if we had
done, perhaps we wouldn't have advanced it.   So why are you now arguing
that the IETF shouldn't do a similarly good job of modeling the threats
around configuring DoH using DHCP?

On Mon, Aug 20, 2018 at 10:51 PM, Paul Vixie <[email-masked]> wrote:

> if you write down trust assumptions you'll be enumerating disjoint sets of
> same as actually practiced by different users and different operators whose
> reasons should be treated as valid rather than challenged.
>
> mine is, i monitor and control the network path between my dhcp client and
> my dhcp server very much more carefully than i can monitor and control the
> network path to RDNS servers. therefore i am comfortable having the former
> introduce me to the latter. other perspectives differ.
>
> --
> P Vixie
>
>

---

From: "John Levine" <[email-masked]>
Date: 20 Aug 2018 23:47:45 -0400

>whose reasons should be treated as valid rather than challenged.

We seem to have one group who see their network operator as a hostile
entity that uses the DNS to censor content and probably stuffs ads
instead of NXDOMAIN.

The other group sees the network operator as a major line of defense
against malware, phishes, and all of the other evil stuff on the
Internet, making it harder for the naive and wilfully clueless to
hurt themselves.*

The two aren't mutually exclusive but it is my impression that unless
you live a country toward the repressive end of the spectrum, your
network is likely to do more of the latter than the former, and if you
are in repression land, they probably have a firewall that will keep
DoH from doing what the first group believes it will.

R's,
John

* - When I talk to security people at mail providers, they have
endless tales of people who take the mail out of their spam folder and
click on the links, you know, just in case it was filtered wrong.  If
you know it's bad stuff, you don't want the users to see it at all.

---

From: Bill Woodcock <[email-masked]>
Date: Mon, 20 Aug 2018 21:22:46 -0700

> On Aug 20, 2018, at 6:40 PM, Paul Ebersman <[email-masked]> wrote:
> 
>> pusateri> There was general
> DHCP is how hotspots, ISPs and enterprise work.

My experience corroborates Paul’s observation.

> have a slew of non-standard ways of doing it and we've helped noone.

…and I agree with his conclusion.

                                -Bill

---

From: Doug Barton <[email-masked]>
Date: Mon, 20 Aug 2018 21:52:39 -0700

> …and I agree with his conclusion.

+1, FWIW

---

From: Doug Barton <[email-masked]>
Date: Mon, 20 Aug 2018 21:59:13 -0700

> 53 traffic and see if there's crap in there; they can't see the inner 

Paul,

You, like Ted, are looking at the problem the wrong way 'round. The USER 
is no worse with a DOH/DOT DHCP option than they are with the existing 
resolver option. 99.<many more 9s>% of users don't even know what DHCP 
is, they just want to connect their iDevice to the coffee shop WiFi.

Unless you can show how the user is harmed by the option, it's silly to 
oppose it.

Now, the network operator may very well be harmed by not being able to 
see the user's DNS traffic, if they are not the ones operating the 
resolver; because their opportunities to monetize NXDOMAIN, sell user 
data, etc. may be reduced, or go away entirely. If they ARE operating 
the resolver, they can still see all the DNS traffic they want to. And 
operators in the former case won't use the option anyway.

So again, what is the harm, to real world users, for having DHCP options 
to configure DOH or DOT?

---

From: Petr Špaček <[email-masked]>
Date: Tue, 21 Aug 2018 08:37:17 +0200

> the user is most likely to need based on previous statistics and

Could you elaborate how DOH helps here? I can't see it now.

We already have RFC 7901 (Chain Query requests in DNS) which allows
resolvers to get all RRs required for DNSSEC validation in one round
trip even over "classic" DNS.

This haven't been implemented because up to know browser vendors have
not been interested in DNSSEC which consequently lead us (resolver
vendors) to ignore complex RFC with no demand.

>From my point of view DOH does not change anything in this regard,
complexity on stub & resolver side is the same no matter what transport
is used.

What am I missing? How does DOH help with this complexity when compared
to classical DNS?

Petr Špaček  @  CZ.NIC

> Tom
> 
>> On Aug 20, 2018, at 10:31 PM, Tom Pusateri <[email-masked]
>> <mailto:[email-masked]>> wrote:
>>
>>> Of course, the question is, how does the consumer of that data decide
>>> what is okay and what's not?   We can't just say that the server has
>>> to behave correctly: someone has to enforce it.
>>>
>>>     > if DOH is widely used by criminals, botnets, and malware to
>>>     bypass perimeter security policy, then there will be a big
>>>     problem and we will be solving it for many years to come, even if
>>>     the browser is the only thing using it. browsers are where most
>>>     modern vulns have occurred, and i expect that trend to
>>>     accelerate. "because that's where the money was.”
>>>
>>>     If web servers did DNSSEC validation and only served addresses
>>>     for names that were validated, I wouldn’t have a problem with
>>>     that at all.
>>>
>>>     If web servers only served addresses for names within the domain
>>>     of the web server, I wouldn’t have a problem with that either.
>>>

---

From: Marek Vavruša <[email-masked]>
Date: Tue, 21 Aug 2018 00:30:01 -0700

> What am I missing? How does DOH help with this complexity when compared

I think Tom is referring to the h/2 push semantics. The resolver can
push the trust chain records
ahead of time, so the forwarder will already have them in cache when
revalidating the final answer.

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Aug 2018 12:33:56 +0200 (CEST)

> Il 20 agosto 2018 alle 18.51 Ted Lemon <[email-masked]> ha scritto: 
> 
> 
> No, it's not bad.   It's the service they offer, and it's fine that they offer it.   I think it's the right default.   It's also fine that I choose to bypass it.

If I got it well, what you are trying to bypass is your ISP's security filter that prevents you from connecting to malware or to illegal content (e.g. intellectual property violations and the likes). I also imagine that your ISP is doing some transparent proxying/scanning so that you cannot simply bypass this filter by configuring a different resolver in your OS, right? (which, by the way, is the simple solution to your problem that is already available and widely used across the world - see the famous picture of people painting 8.8.8.8 on walls in Turkey)
 
If so, I can accept your use case: a smart user, knowing what he is doing, does not want anyone else to sanitize his queries for him. But I don't see why the best solution to your use case - which is quite a minority case, though easily overrepresented in a technical environment - is to build a sort of "nuclear bomb" protocol that, if widely adopted, will destroy most of the existing practices in the DNS "ecosystem" (I'm using the word that was being used at ICANN's DNS Symposium in Montreal), including the basic security measures that protect the 99.9% of the users who are not technically smart. Perhaps it would have been enough for you to have a discussion with your ISP and get them to give you an opt-out, which is entirely possible with today's DNS filtering techniques - or to just change to another ISP.
 
Anyway, this looks to me a lot like a policy issue, rather than a technical one; and the more I get into this discussion, the more DoH looks like "the IETF against the world's governments and ISPs" - not a good thing, IMHO.

> Yes, and if we come up with a solution that allows both situations to be securely communicated to the end user device, and allows the end user to make an informed decision about whether or not to use the service with these restrictions in place, I'm okay with that, and I think it's appropriate for the IETF to do it.   What I am arguing is that we should actually describe how to do that, and not just hack together a solution without thinking about that.

I would be fine with this approach and happy to work on it, as long as there is an agreement by the DoH/browsers community that DoH will not be deployed to the general public until this missing piece is completed and implemented. Otherwise it would just be a waste of time.

Regards, 
--

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Aug 2018 12:40:40 +0200 (CEST)

> Il 20 agosto 2018 alle 20.11 Paul Vixie <[email-masked]> ha scritto:
> the DOH people should be told not to proceed to draft 

This is, honestly, what I'd have expected the "IETF leadership" (IESG, IAB...) to say: this new protocol would have a significant impact on how the Internet works, there are conflicting views in different parts of the IETF community and a lot of non-technical concerns outside of it, please work on it until everyone is happy. But possibly I don't understand how the IETF works yet.

Regards,

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Aug 2018 12:45:52 +0200 (CEST)

> Il 21 agosto 2018 alle 5.47 John Levine <[email-masked]> ha scritto:

It's true, and there is an additional consideration to this: the users that do so are not just damaging themselves, but everyone else, by spreading the infections and becoming attack vectors. I understand why some people are conceptually irked by the idea that the ISP can decide on its own to make something unreachable to them, but they should understand that most Internet users are not technically savvy, often not savvy at all, and this threatens the Internet as a whole.

Regards,
--

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Aug 2018 12:15:59 +0100

> from their normal DNS resolvers, so maybe it's a bad idea :-)

There was an interesting discussion on Twitter last night -
https://twitter.com/PowerDNS_Bert/status/1031284355686178817

Bert Hubert made the point that https has a lot more opportunities for
identifying and tracking individual devices, compared to trad DNS. Home
gateways that act as DNS relays help with individual privacy, especially
if they also cache.

I think the implications of this, and the arguments that Paul Vixie has
been making, are that there will be unexpected privacy and security upsets
if the DoH resolution path is too different from the trad DNS resolution
path.

This is really a problem with how DoH is deployed and used. So it's
important to make it easy for operators to deploy DoH in a way that
doesn't have surprising privacy leaks when it is supposed to be a
privacy-enhancing technology. DHCP options can help to make all the
DoTH stuff behave in a similar way to the network's trad DNS - it's much
simpler from the user's perspective if they only need to worry about how
respectful or abusive their network provider is as a whole, without having
to get into the details of exactly which resolution protocol they are
using.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Humber, Thames, Dover: Southwest 4 or 5, occasionally 6, except in Humber.
Slight, occasionally moderate. Fog patches at first. Moderate or good,
occasionally very poor at first.

---

From: Tony Finch <[email-masked]>
Date: Tue, 21 Aug 2018 12:33:05 +0100

Tom Pusateri <[email-masked]> wrote:

> required for validating up (down) the chain,

With DNS to a recursive server (UDP, TCP, or TLS) as currently deployed,
you only need 1 round trip in simple cases or 2 round trips if there's a
CNAME or SRV (etc.) because you know ahead of time all the queries you
need to make to get the validation chain and they can trivially be
pipelined.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
individual and social justice

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 08:48:32 -0400

On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton <[email-masked]> wrote:

> You, like Ted, are looking at the problem the wrong way 'round.

And this, in a nutshell, is why this discussion has gone on so long.   If
you just caricature what the people you're conversing with say, then it's
inevitably going to go like this:

Person A: I think that there are some issues here that we need to consider,
and that your use model is the not the only use model we need to think
about.
Person B: You want the malware operators to take over the Internet
Person A: No, I didn't say that.   I get that your use model makes sense to
you, and we should address your use model.   I'm just saying it's not the
only use model we should address
Person B: Right, you're saying that I shouldn't be able to control what
happens on my network.
Person A: No, I'm really not saying that.   I'm saying we need to consider
other use cases as well.
Person B: So you're saying that we should also consider the use case where
you want to be able to bypass my controls and let the malware operators
control my network.
Person A: No, I'm NOT saying that.   I'm saying that there are legitimate
reasons why people might want to bypass DNS resolvers.
Person B: So you're helping the malware operators.

This is why discussions balloon in the IETF.   So now I have the choice of
either being silenced, or continuing to be Person A in this charade.   I
think I've spoken my peace.   If you want to proceed with this work, please
do not be surprised if, when the call for adoption comes, I come in and say
"I raised substantive objections to this, which were not addressed, so
please do not take this on as a working group item."

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Aug 2018 16:47:15 +0200

> If I got it well, what you are trying to bypass is your ISP's
> security filter that prevents you from connecting to malware or to
> illegal content (e.g. intellectual property violations and the
> likes). 

As a user, I think there is little reason to trust an ISP.

If you take a mobile device, do you trust every hotel, bar, etc. where you
may connect to the wifi? Are they all competent? Are you sure none of them will
violate your privacy?

If you have only a few ISPs to chose from, do you trust that ISP?

There are many ISPs that try to do the right thing for their customers.
There are quite a few ISPs that have court orders to do things that go against
the interests of their customers.
And the are quite a few ISPs that are positively evil.

You need to have options in case you can't trust the ISP.

> build a sort of "nuclear bomb" protocol
> that, if widely adopted, will destroy most of the existing practices
> in the DNS "ecosystem" 

There is no reason why DoH has to be deployed as a 'nuclear bomb'.

Hosts can still default to using the resolvers offered by DHCP only switching
to public resolvers when directed by the user.

The big difference is that when the user does decide to bypass the ISP's
resolvers, there will be no way for the ISP to interfere.

Of course, an ISP can still try to block encrypted access to 8.8.8.8, etc.
Ultimately, that may result in users routing their requests over tor. In
areas with netneutrality laws, blocking access to public resolvers is probably
not an option.

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 21 Aug 2018 17:01:17 +0200

> may connect to the wifi? Are they all competent? Are you sure none of them will

Then you have a problem that's not solvable in DNS itself (yet).  That's
what people usually forget to consider.

The hostnames are clear-text in https hanshakes (so far), and it seems
relatively easy to collect those.  So, by tunneling *only* DNS you don't
make it much more difficult for the ISP, and in addition you share the
names with some other party.  That doesn't sound very appealing to me
personally, from privacy point of view at least.  (On the other hand,
big resolvers will have lots of cached answers, etc.)

https://tools.ietf.org/html/draft-rescorla-tls-esni-00

After SNI encryption gets widely deployed, tracking through IP addresses
only will be somewhat harder, so there it will start getting
interesting.  Until then, IMHO you just need to either trust the ISP or
tunnel *all* traffic to somewhere, e.g. via tor or VPN to some trusted
party.

--Vladimir

---

From: Vittorio Bertola <[email-masked]>
Date: Tue, 21 Aug 2018 17:23:42 +0200 (CEST)

> Il 21 agosto 2018 alle 16.47 Philip Homburg <[email-masked]> ha scritto:
> 
> 

Sure, roaming at hotels and cafes is a good use case for encrypted DNS, though for many people it is not the typical Internet access situation (not everyone travels to conferences all the time). Most people here in Europe either access the Internet at home or at work through DSL or fiber, or access it on their mobile phone using the mobile operator's data network. In fact, roaming wi-fi connections, while still relevant (especially for international tourists), are getting less and less used, since everyone now gets several gigabytes of EU-wide mobile data per month included with their base mobile fee.

Still, I'm all in favour of encrypting and authenticating DNS connections when you are in that situation. However, this should not be done in a way that breaks many other use cases.

> If you have only a few ISPs to chose from, do you trust that ISP?

How many browsers can I choose from? Definitely many less than the possible ISPs, and not a single one from the jurisdiction I live in.
 
> There are quite a few ISPs that have court orders to do things that go against the interests of their customers.

Yes, but that's the law. I still don't get how is it possible that the IETF is releasing a technology openly designed to allow people to break the law. In my part of the world, this is ethically unacceptable, and possibly also illegal.

> You need to have options in case you can't trust the ISP.

Why would you ever use an ISP that you don't trust and that is positively evil?

> There is no reason why DoH has to be deployed as a 'nuclear bomb'.

Ok, this is the real issue. There is no reason why, but this is how it is being deployed, starting with Mozilla. And I have yet to see a statement from the DoH community that Mozilla's idea of making DoH the default and disregarding whatever resolver is being configured in the system via DHCP is not a good one. Actually, during the discussions in Montreal there were people talking about centralized DNS operators paying the browser makers to get their DNS traffic, and then monetizing it to get back the money. How can this be presented as "more privacy" is baffling.

Perhaps what we are missing is just a set of policy guidelines on how DoH should be deployed by operators and application developers, though I do not know how you could then enforce them.

> to public resolvers when directed by the user.

No, they can't, if the application defaults to its own resolvers, possibly not even letting the user choose different resolvers unless they click into three-level-deep configuration menus.

> resolvers, there will be no way for the ISP to interfere.

Good luck explaining that to several hundred governments that rely on mandatory DNS filters to enforce gambling, hate speech and pornography regulation.

Regards,
--

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Aug 2018 17:34:44 +0200

>big resolvers will have lots of cached answers, etc.)

This is too some extent a chicken and egg problem. Without encrypted DNS 
there is no point in encrypted SNI and vice versa.

I expect that encrypted SNI will be relatively easy to deploy. It can happen
as soon as both endpoints support it.

In contrast, DNS is a very complex eco system. So it makes sense to start
deploying encrypted DNS now, under the assumption that encrypted SNI will
follow.

>interesting.

We have seen already that 'domain fronting' is can be a very effective way
to bypass filters. For large CDNs or cloud providers, filtering based on 
IP addresses is not going to be effective.

>Until then, IMHO you just need to either trust the ISP or

True. But we can take small steps to reduce unwanted interference from ISPs.

>From a security point of view, it helps a lot if you can just trust DNS.
Instead of always having to take into account that somebody may interfere 
with DNS replies.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 12:09:15 -0400

On Tue, Aug 21, 2018 at 11:23 AM, Vittorio Bertola <
[email-masked]> wrote:

> Still, I'm all in favour of encrypting and authenticating DNS connections
> when you are in that situation. However, this should not be done in a way
> that breaks many other use cases.
>

How do we know when we are in that situation and not in some other
situation?   I think this is a solvable problem, but we have to say what
the solution is.   That's what I've been advocating for here.

Yes, but that's the law. I still don't get how is it possible that the IETF
> is releasing a technology openly designed to allow people to break the law.
> In my part of the world, this is ethically unacceptable, and possibly also
> illegal.
>

It's illegal in some countries for women to drive.   Should we stop making
cars?   Is it ethically unacceptable to make cars because women might use
them to violate this law in jurisdictions where it exists?

Why would you ever use an ISP that you don't trust and that is positively
> evil?

There is often no alternative.

> Ok, this is the real issue. There is no reason why, but this is how it is
> being deployed, starting with Mozilla. And I have yet to see a statement
> from the DoH community that Mozilla's idea of making DoH the default and
> disregarding whatever resolver is being configured in the system via DHCP
> is not a good one. Actually, during the discussions in Montreal there were
> people talking about centralized DNS operators paying the browser makers to
> get their DNS traffic, and then monetizing it to get back the money. How
> can this be presented as "more privacy" is baffling.
>

The DoH community does not have consensus on this, so it can't make a
statement about it.

> Perhaps what we are missing is just a set of policy guidelines on how DoH
> should be deployed by operators and application developers, though I do not
> know how you could then enforce them.
>

We can't write a set of policy guidelines.   That's an issue that will vary
by jurisdiction.   What we can do is document the threat model, document
the use cases, and talk about how to address them.

---

From: Vladimír Čunát <[email-masked]>
Date: Tue, 21 Aug 2018 18:19:39 +0200

Ehm, we somehow forgot that this thread is supposed to be about DHCP, so
that's only the "uninteresting" case where you do trust the ISP and want
to use their DNS over a secure channel :-D

On 08/21/2018 05:34 PM, Philip Homburg wrote:
>> [...]

Yes, partially.

> deploying encrypted DNS now, under the assumption that encrypted SNI will

Well, DoT has been standardized for some time, and we now have multiple
open-source implementations for client- and daemon-side, and some large
public services support it.  DoH is a little later, but it might gather
more speed eventually.  From *my* point of view the SNI is the biggest
hindrance ATM; other technical issues don't seem bad, at least not for
most motivated users.  (Finding a trusted service might be problem for
some people, I suspect.)

> IP addresses is not going to be effective.

Centralizing most of the traffic to a few CDN providers would solve
that, but somehow I don't think privacy should depend on that.  And I
don't think it's so easy to significantly reduce the information leak -
you just *move* it to somewhere else (someone else), and it's not really
clear to me in general who is more trustworthy.  Still, such
possibilities certainly are nice to have.

> Instead of always having to take into account that somebody may interfere 

Defense against changing DNS is something else than privacy - we have
DNSSEC for that, so you don't even need to trust the server sending you
the data, but I think we're getting too much off-topic anyway...

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 12:25:30 -0400

DHCP is automatic, so the question of what to do when you have
configuration information that conflicts with DHCP needs to be addressed.
 It isn't "simple" simply because it addresses only one specific use case.

On Tue, Aug 21, 2018 at 12:19 PM, Vladimír Čunát <[email-masked]

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 21 Aug 2018 12:47:25 -0400

> On Aug 21, 2018, at 3:30 AM, Marek Vavruša <mvavrusa=[email-masked]> wrote:
> 
> On Mon, Aug 20, 2018 at 11:37 PM, Petr Špaček <[email-masked] <mailto:[email-masked]>> wrote:

Yes, plus the fact that the web/DoH server already knows all of the questions you might ask because it just fed you a page of content with links.

The Chain Query Requests in DNS (RFC 7901) are awesome for the stub resolver. But the web/DoH server has more knowledge that the stub doesn’t have yet and so it can benefit from this knowledge in a way that the stub resolver can’t.

Tom

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 21 Aug 2018 12:51:33 -0400

> On Aug 21, 2018, at 7:33 AM, Tony Finch <[email-masked]> wrote:
> 

Yes, and with CHAIN Query Requests in DNS it’s even better. But this still can’t beat the fore knowledge the web/DoH server has about the page you’re viewing. The web/DoH server can HTTP/2 Push all of validation records for links you MAY click on in the future while you’re reading the page, taking into account the scroll position of your page. The validation can then be done in the browser before you click on the link and once you do, the browser knows the address and has validated it.

Tom

---

From: David Conrad <[email-masked]>
Date: Tue, 21 Aug 2018 10:36:46 -0700

Vittorio,

On Aug 21, 2018, at 3:33 AM, Vittorio Bertola <[email-masked]> wrote:
> If so, I can accept your use case: a smart user, knowing what he is doing, does not want anyone else to sanitize his queries for him. But I don't see why the best solution to your use case - which is quite a minority case, though easily overrepresented in a technical environment - is to build a sort of "nuclear bomb" protocol that, if widely adopted, will destroy most of the existing practices in the DNS "ecosystem" (I'm using the word that was being used at ICANN's DNS Symposium in Montreal), including the basic security measures that protect the 99.9% of the users who are not technically smart. 

Perhaps I’m misunderstanding: are you saying the folks who provide resolution services in a DoH world would have incentive to not follow basic security measures?

Regards,
-drc

---

From: Bob Harold <[email-masked]>
Date: Tue, 21 Aug 2018 13:52:41 -0400

On Tue, Aug 21, 2018 at 1:37 PM David Conrad <[email-masked]> wrote:

> Vittorio,
>
> On Aug 21, 2018, at 3:33 AM, Vittorio Bertola <
> If so, I can accept your use case: a smart user, knowing what he is doing,
> does not want anyone else to sanitize his queries for him. But I don't see
> why the best solution to your use case - which is quite a minority case,
> though easily overrepresented in a technical environment - is to build a
> sort of "nuclear bomb" protocol that, if widely adopted, will destroy most
> of the existing practices in the DNS "ecosystem" (I'm using the word that
> was being used at ICANN's DNS Symposium in Montreal), including the basic
> security measures that protect the 99.9% of the users who are not
> technically smart.
>
>
> Perhaps I’m misunderstanding: are you saying the folks who provide
> resolution services in a DoH world would have incentive to not follow basic
> security measures?
>
> Regards,
> -drc
>

At my university, our security group watches DNS rpz logs and DNS traffic
logs for signs of malware, and takes action.  In a DoH world, I cannot
imagine every third-party DoH provider giving our security group that
information.  They will follow their own security measures, but will still
affect ours because we lose visibility.

-- 
Bob Harold

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 13:59:12 -0400

This is one of the problems with security.   It always comes with
tradeoffs, and it always looks different depending on your perspective.
 In fact, though, the people who are currently providing DoH service
actually have much greater visibility into the malware problem than you
possibly can.   This doesn't mean that it doesn't suck for you to not be
able to collect the data, because at a university you presumably want to be
able to do research on the data.   But that's one of the tensions here.
 The answer to the observation "security requires us to make unpalatable
tradeoffs" is not "don't do security."

On Tue, Aug 21, 2018 at 1:52 PM, Bob Harold <[email-masked]> wrote:

>> If so, I can accept your use case: a smart user, knowing what he is
>> doing, does not want anyone else to sanitize his queries for him. But I
>> don't see why the best solution to your use case - which is quite a
>> minority case, though easily overrepresented in a technical environment -
>> is to build a sort of "nuclear bomb" protocol that, if widely adopted, will
>> destroy most of the existing practices in the DNS "ecosystem" (I'm using
>> the word that was being used at ICANN's DNS Symposium in Montreal),
>> including the basic security measures that protect the 99.9% of the users
>> who are not technically smart.
>>
>>

---

From: Jim Reid <[email-masked]>
Date: Tue, 21 Aug 2018 19:32:20 +0100

On 21 Aug 2018, at 16:23, Vittorio Bertola <[email-masked]> wrote:
> 
> And I have yet to see a statement from the DoH community that Mozilla's idea of making DoH the default and disregarding whatever resolver is being configured in the system via DHCP is not a good one.

Why would/should the DoH community -- whatever that is -- make such a statement? In some cases, it will be better to use the current network’s resolving DNS servers. In others it won’t. For some definition of “better”. The use or non-use of DoH is somewhat orthogonal to those underlying considerations. 

Deciding what’s “good” or “bad" gets very messy very quickly. For instance I might decide to trust $coffeeshop’s resolver in my home town (say) but not at a branch of $coffeeshop that's behind the Great Firewall of China. Or $coffeeshop’s outlet in the foyer of my employer’s building.

> Actually, during the discussions in Montreal there were people talking about centralized DNS operators paying the browser makers to get their DNS traffic, and then monetizing it to get back the money. How can this be presented as "more privacy" is baffling.

If this happens, it can be worked around. Almost nobody is going to be forced to use privacy-unfriendly browsers or resolvers at gunpoint. Besides, providers offering “even more privacy” will emerge if this centralisation/monetisation thing turns out to be a problem. Having low barriers to entry is one of the nice things about the Internet. Well OK, it’s a nice thing some of the time. :-)

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Aug 2018 11:41:40 -0700

> As a user, I think there is little reason to trust an ISP.

while any company can be scummy, some aren't. the ISP in this case may 
be a value added security vendor who also offers IP transit. if you want 
to do business with a scummy ISP, or if you have no choice, then they 
should still have the ability to transparently prevent you from doing 
things you want to do. (transparently means you know it's happening and 
can decide to just unplug if you don't like it.)

my ISP is comcast, and i use their RDNS servers as backups to my own, 
because i trust them to run dnssec and rdns, and to not filter content. 
your perspective may differ; one trust model will not fit all situations.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Aug 2018 11:54:23 -0700

David Conrad wrote:
> resolution services in a DoH world would have incentive to not follow
> basic security measures?

noting that i am not vittorio, i will punch in as follows.

i do not expect CF to block resolution of its free-tier of CDN 
pseudo-customers; if they thought those folks didn't deserve DNS, they 
would probably think they didn't deserve CDN services either.

i block quite a few free-tier CF CDN pseudo-customers here, because that 
service tier is widely abused. since the addresses associated with these 
low-value pseudo-customers are shared by their paying customers, i can't 
block them at the IP layer. so i block them using DNS RPZ. (i do not 
publish this RPZ because in 1997 or so i got tired of lawsuits.)

anyhow, this is but one of many reasons why i don't want control-plane 
information injected into my network, bypassing my security perimeter. 
while CF is a special case, the general case is where my policies are 
aligned somewhat differently than the user's policies or the content 
provider's policies or the "public DoH" server operator's policies.

my network, my rules. one rule is, no bot-on-bot violence in my house.

-- 
P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Aug 2018 12:23:30 -0700

Tom Pusateri wrote:
...
> The Chain Query Requests in DNS (RFC 7901) are awesome for the stub
> resolver. But the web/DoH server has more knowledge that the stub
> doesn’t have yet and so it can benefit from this knowledge in a way that
> the stub resolver can’t.

for this to matter, the user will either have to visit a very large 
number of completely unrelated destinations, or will have to visit the 
same site or site-cluster many times. i consider the former unlikely, 
and have therefore limited my thinking to the latter.

in the case where someone is visiting the same site or site-cluster many 
times, the cost of fetching the necessary crypto-chain materials will 
only be borne once, or at worst very infrequently, due to caching.

this means that the difference between having the crypto-chain pushed to 
you in advance by someone who can predict where you're about to go 
because they're also sending you content with those references, will be 
so rare as to be non-impacting.

in addition, DoH is not connected to web service in any necessary way. 
the DoH channel will be to a DoH provider such as CF. while there's a 
good chance in today's internet that you'll also be fetching content 
from CF, there are in fact other CDN's and many non-CDN content hosts. 
if you are talking to any content host other than CF, then the CF DoH 
service will have no knowledge of what to push toward you.

in further addition, even in the case where you have a persistent CF DoH 
connection open, it may not be easy for CF to share enough 
connection-state between its DoH and other-content servers so that the 
one will be able to push crypto-chain information to you in support of 
the other.

in short, i don't think DoH can usefully optimize by pushing.

-- 
P Vixie

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 21 Aug 2018 15:24:19 -0400

> On Aug 21, 2018, at 2:54 PM, Paul Vixie <[email-masked]> wrote:
> 
> 
> 
> David Conrad wrote:
>> Vittorio,
>> 
>> ...
>> 
> i do not expect CF to block resolution of its free-tier of CDN pseudo-customers; if they thought those folks didn't deserve DNS, they would probably think they didn't deserve CDN services either.
> 
> i block quite a few free-tier CF CDN pseudo-customers here, because that service tier is widely abused. since the addresses associated with these low-value pseudo-customers are shared by their paying customers, i can't block them at the IP layer. so i block them using DNS RPZ. (i do not publish this RPZ because in 1997 or so i got tired of lawsuits.)
> 
> anyhow, this is but one of many reasons why i don't want control-plane information injected into my network, bypassing my security perimeter. while CF is a special case, the general case is where my policies are aligned somewhat differently than the user's policies or the content provider's policies or the "public DoH" server operator's policies.
> 

Ok, so as Vladimír said, getting back to DHCP…

1. You obviously don’t need a DoH URI option for DHCP.
2. You’re comfortable with DNS over UDP/53 as long as DNS Cookies are present and using the existing DHCP DNS options
3. You seem happy with the Android approach of just trying DoT with the IP address learned via standard DHCP DNS options

Why do you care about additional DHCP options?

Thanks,
Tom

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Aug 2018 12:30:02 -0700

this, joyfully, is a very good question.

Tom Pusateri wrote:
...
> 1. You obviously don’t need a DoH URI option for DHCP. 2. You’re
> comfortable with DNS over UDP/53 as long as DNS Cookies are present
> and using the existing DHCP DNS options 3. You seem happy with the
> Android approach of just trying DoT with the IP address learned via
> standard DHCP DNS options
>

in my previous explaination as to the security model i follow, i noted 
that the network paths to my dhcp server and my rdns servers were 
different, and that in the dhcp case i have far more observability and 
control than in the rdns case.

it should follow therefore that i do NOT want to use UDP/53 + Cookies 
unless there is no alternative. DoT will be preferred. (DTLS or SCTP 
would be even better, but i'm only picking from items now-on-menu.)

-- 
P Vixie

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Aug 2018 21:33:17 +0200

>In fact, roaming wi-fi 
>connections, while still relevant (especially for international tourists), are
> getting less and less used, since everyone now gets several gigabytes of EU-w
>ide mobile data per month included with their base mobile fee.

I assume that you are aware that with HD video, you can easily burn through a
couple of Gbyte in an hour.

>How many browsers can I choose from? Definitely many less than the possible IS
>Ps, and not a single one from the jurisdiction I live in.

Many places have essentially two landline options. Only 3 mobile network is
also quite common. 

In addition, two serious browsers are open source. And there are firefox
forks that try to fix some of the damage done by mozilla.

>Yes, but that's the law. I still don't get how is it possible that the IETF is
> releasing a technology openly designed to allow people to break the law. In m
>y part of the world, this is ethically unacceptable, and possibly also illegal
>.

It is not that black and white. In the Netherlands, a few ISPs are forced to
block access to The Pirate Bay.

That court order applies only to those ISPs, consumers are completely free
to visit The Pirate Bay.

>No, they can't, if the application defaults to its own resolvers, possibly not
> even letting the user choose different resolvers unless they click into three
>-level-deep configuration menus.

Anybody can write an application that does weird stuff. That's not something
a RFC can prevent.

>Good luck explaining that to several hundred governments that rely on mandator
>y DNS filters to enforce gambling, hate speech and pornography regulation.

Governments will figure out that eventually protocols that communicate in
plaintext will die out. Of course, they can mandate the use of plaintext in
their respective countries, at their own economic disadvantage.

---

From: Tom Pusateri <[email-masked]>
Date: Tue, 21 Aug 2018 15:39:57 -0400

> On Aug 21, 2018, at 3:30 PM, Paul Vixie <[email-masked]> wrote:
> 
> in my previous explaination as to the security model i follow, i noted that the network paths to my dhcp server and my rdns servers were different, and that in the dhcp case i have far more observability and control than in the rdns case.
> 
> it should follow therefore that i do NOT want to use UDP/53 + Cookies unless there is no alternative. DoT will be preferred. (DTLS or SCTP would be even better, but i'm only picking from items now-on-menu.)

Since you can already do DoT today without an additional DHCP DNS option and adding that option will indisputably also come with a DoH URI option too, I would think you would be arguing against any new DHCP options for consistency.

Tom

---

From: Philip Homburg <[email-masked]>
Date: Tue, 21 Aug 2018 21:43:19 +0200

>to use their DNS over a secure channel :-D

There are still plenty of use cases. An ISP may not want to run a recursive
resolver and instead refer to a public resolver using DHCP.

Additionally, on an open wifi, encrypting DNS traffic can help against 
snooping. So it is in the ISP's interest to announce that the local
recursive resolvers support DoH

>most motivated users.  (Finding a trusted service might be problem for

For DNS, code is not enough. You need to get admins of recursive resolvers
to upgrade. And there are lots of those resolvers. Many of them almost
unmanaged.

DNS is for a large part not end-to-end. You have the recursive resolvers
as middle men.

>the data, but I think we're getting too much off-topic anyway...

DNSSEC is part of the puzzle, but leaves a lot of holes:
- Currently very few systems ship with locally validating resolvers. So
  most systems can be attacked on the last mile.
- Many domains are not signed for one reason or another. 
- Even with DNSSEC, an on path attacker can see the queries and selectively
  mount a denial of service attack.

DoH protects the last mile from all of those attacks.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 21 Aug 2018 13:09:08 -0700

Tom Pusateri wrote:
...
>> it should follow therefore that i do NOT want to use UDP/53 +
>> Cookies unless there is no alternative. DoT will be preferred.
>> (DTLS or SCTP would be even better, but i'm only picking from items
>> now-on-menu.)
>
> Since you can already do DoT today without an additional DHCP DNS
> option and adding that option will indisputably also come with a DoH
> URI option too, I would think you would be arguing against any new
> DHCP options for consistency.

no, sir. i must have misspoke. i have DoT available, but nothing uses 
it, though i am expecting android 9 ("Pie") which dropped yesterday to 
start opportunistically doing so. if that's the behaviour we want for 
stubs, we should document it instead of adding anything to DHCP.

-- 
P Vixie

---

From: Doug Barton <[email-masked]>
Date: Tue, 21 Aug 2018 20:03:36 -0700

On 08/21/2018 05:48 AM, Ted Lemon wrote:
> On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton <[email-masked] 
> And this, in a nutshell, is why this discussion has gone on so long.  
>   If you just caricature what the people you're conversing with say, 
> then it's inevitably going to go like this:

[ Snipped a bunch of arguments I didn't make ]

> This is why discussions balloon in the IETF.   So now I have the choice 
> of either being silenced, or continuing to be Person A in this charade.  
>   I think I've spoken my peace.   If you want to proceed with this work, 
> please do not be surprised if, when the call for adoption comes, I come 
> in and say "I raised substantive objections to this, which were not 
> addressed, so please do not take this on as a working group item."

Ted,

While I'm not concerned about the issues you raised in your caricature, 
I feel that I have tried to engage you in your discussion of different 
security models. My understanding is that your models devolve down to 
two. Either the user configures a resolver themselves (whether it's 
DOH/DOT or not), and user doesn't configure a resolver themselves. I 
recognize the distinction you made between your models 1 and 3, and 
further recognize that it's extremely important to some people. My point 
is that *from the standpoint of a DHCP option for DOH/DOT* it's not 
relevant.

 From our discussion, it seems that you're in agreement with me that if 
a user isn't configuring a resolver explicitly that they are no worse 
off with DOH/DOT than they are without it. Am I right so far?

Meanwhile, you've also voiced an opinion that the presence of a DHCP 
option implies some sort of endorsement by the IETF. I (and others) 
replied that we've never heard of this, and disagree strongly with your 
position.

So other than the fact that we disagree on the endorsement issue, what 
am I missing here?

Doug

---

From: Ted Lemon <[email-masked]>
Date: Tue, 21 Aug 2018 23:11:01 -0400

We aren’t even talking about the same thing. I’m talking about figuring out
whether we need to offer guidance for how a host implementation would
handle conflicting information and, if so, what guidance to offer.  You are
talking about one of a number of different ways of configuring DoT.

---

From: Doug Barton <[email-masked]>
Date: Tue, 21 Aug 2018 22:05:39 -0700

What conflicting information?

On 08/21/2018 08:11 PM, Ted Lemon wrote:
> We aren’t even talking about the same thing. I’m talking about figuring 
> out whether we need to offer guidance for how a host implementation 
> would handle conflicting information and, if so, what guidance to 
> offer.  You are talking about one of a number of different ways of 
> configuring DoT.
> 
> On Tue, Aug 21, 2018 at 11:04 PM Doug Barton <[email-masked] 
>      > On Tue, Aug 21, 2018 at 12:59 AM, Doug Barton
>     <[email-masked] <mailto:[email-masked]>
>      > <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>      >

---

From: Doug Barton <[email-masked]>
Date: Tue, 21 Aug 2018 22:15:03 -0700

On 08/21/2018 09:25 AM, Ted Lemon wrote:
> configuration information that conflicts with DHCP needs to be 
> addressed.   It isn't "simple" simply because it addresses only one 
> specific use case.

If your "conflicting information" issue is "What do I do with DHCP 
options I receive for things I've already configured manually?" when has 
the answer ever been anything other than, "Ignore them?"

Are there seriously cases where a DHCP option would override something 
I've manually configured already?

---

From: Doug Barton <[email-masked]>
Date: Tue, 21 Aug 2018 22:18:55 -0700

On 08/21/2018 09:19 AM, Vladimír Čunát wrote:
> to use their DNS over a secure channel:-D

This perspective that users "trust" their network environment is deeply 
flawed. Users don't understand how any of this stuff works, and we 
should not be making any decisions with that as a premise.

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 22 Aug 2018 10:22:39 +0200 (CEST)

> Il 22 agosto 2018 alle 7.18 Doug Barton <[email-masked]> ha scritto:

But we should also not make the premise that the user does not trust the network environment. It really depends on the situation.

Also, there are cases in which the user perhaps does not trust his network, but his network has the right to enforce policies on the user: think at the employees on a corporate network. We should be making this enforcement easier, not harder - for example, adding ways for the network operator to communicate to DoH operators that certain restrictions have to be put in place for the users of its network.

Moreover, even if the user does not trust his network and has the right to do something about this, you cannot also assume that he trusts his application maker or his destination website operator more than he trusts his network. Actually, if you define trust in terms of expectations, until now the users that understand what we are talking about expect their network operator to provide the resolver, not the application maker.

The real problem here is that you cannot establish a trust model that is always valid, and the trust model that applies to a situation can be opposite to the model applying to another one, without any automatable way to distinguish among the two.

This is also what makes this issue so thorny. You can decide that, in the end, the only way to get out of this is to entrust the user with the choice of who to trust, though, as you say, many users will not be able to make an informed choice. Or you can entrust the network operator or the DoH server operator: it is more likely to make competent choices, but in some cases might not make them in the user's interest, though in some cases it also has the right, or even the legal duty, to make choices that users dislike. All in all, I see no easy way to find a model and a policy that work in all cases.

Regards,
--

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 22 Aug 2018 10:32:40 +0200 (CEST)

> Il 21 agosto 2018 alle 19.36 David Conrad <[email-masked]> ha scritto: 
>  
>  Vittorio, 
> 
> 

The definition of what is safe for browsing and what is not is highly local - each network and each country have their policies. How could a QuadX operator implement a filter that fits the needs of the entire planet?

(Unless we imagine a model in which the DoH operator receives policies from networks and countries and applies them depending on where the request is coming from.)

Also, network operators have a direct interest in implementing security measures to prevent threats from spreading to more devices on their network. What's the incentive for a centralized DoH operator to spend money and time in security filters?
 
Regards,
--

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Aug 2018 09:10:34 -0400

Again, to repeat myself once more, one more time, I am asking that we
actually decide what to recommend, and not just say "we all already all
know what the right behavior is."   If we all agreed on what the correct
behavior was, we wouldn't be having this discussion.   Maybe if we tried to
describe what we all think the correct behavior was, we would realize that
we do agree on it, but we haven't done that yet.   And the possible set of
all behaviors is more complicated than you suggest.

On Wed, Aug 22, 2018 at 4:32 AM, Vittorio Bertola <
[email-masked]> wrote:

> The definition of what is safe for browsing and what is not is highly
> local - each network and each country have their policies. How could a
> QuadX operator implement a filter that fits the needs of the entire planet?
>
> (Unless we imagine a model in which the DoH operator receives policies
> from networks and countries and applies them depending on where the request
> is coming from.)
>
> Also, network operators have a direct interest in implementing security
> measures to prevent threats from spreading to more devices on their
> network. What's the incentive for a centralized DoH operator to spend money
> and time in security filters?
>
> Regards,
> --
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Aug 2018 09:42:01 -0700

this will be my last post on this topic; happy to continue on DHCP matters.

Ted Lemon wrote:
> ... In fact, though, the people who are currently providing DoH service
> possibly can. ...

this is a false equivalence.

i have responsibility for my network's security. the DoH provider does not.

i _will_ know what's targetting me. the DoH provider _might_ know.

i know my policies and tradeoffs. the DoH provider will not know.

if i choose to outsource my perimeter defense, that's one thing. but to 
have a visitor or BYOD or malware or employee or family member decide to 
do this, is quite another.

the DoH team has badly misunderstood a full segment of the community, 
and the resulting knee-jerk ignorant politics-based engineering is going 
to have a very long tail of foreseeable negative side effects.

-- P Vixie

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Aug 2018 11:24:07 -0700

Ted Lemon wrote:
> behavior was, we wouldn't be having this discussion.   Maybe if we tried
> to describe what we all think the correct behavior was, we would realize
> that we do agree on it, but we haven't done that yet.   And the possible
> set of all behaviors is more complicated than you suggest.

with regard to dhcp, if the dhc wg is freezing new features pending 
authentication capabilities which are not forthcoming, then dhcp is off 
the table for DoT discovery.

in that case, the purported android approach of "use DoT if it works" 
may be the only way forward. this means when current unauthenticated 
dhcp tells you what your rdns servers are, you'll try each of them with 
TCP/853 and use that if it works, else fall back to whatever you did 
before, which is probably UDP/53 falling back to TCP/53.

-- 
P Vixie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 22 Aug 2018 14:35:00 -0400

It's never been up to the DHC working group to decide whether new DHCP
options are architecturally good.   People have often used the DHC working
group as a way to skate by due diligence on architectural considerations;
this was considered to be a problem even before I was chair, and we burned
a lot of time evaluating bad ideas before we decided not to be the place
where new work on DHCP options is done by default.   If a DHCP option were
to be entertained, this WG, the dprive WG or the DoH WG would be where it
would have to happen, not because the DHC working group is freezing new
features, but because it's not in their charter.

That said, you responded to a message where I talked about what I think we
ought to do to move forward by saying that moving forward is impossible
other than by just adding a hack somewhere.   I don't think that's true,
and in fact I'm feeling like I need to write up a threat analysis because
even though it's not something that I want to work on, it sounds like most
people assume it's impossible and I'm just suggesting it as a roadblock,
and the people who get that it's necessary don't seem to be any more
enthusiastic about doing it than I am.   I'd appreciate it if, when I've
written that analysis, you could contribute to it, but I'll understand if
you don't have time or don't think it's worthwhile.

On Wed, Aug 22, 2018 at 2:24 PM, Paul Vixie <[email-masked]> wrote:

> authentication capabilities which are not forthcoming, then dhcp is off the
> table for DoT discovery.
>
> in that case, the purported android approach of "use DoT if it works" may
> be the only way forward. this means when current unauthenticated dhcp tells
> you what your rdns servers are, you'll try each of them with TCP/853 and
> use that if it works, else fall back to whatever you did before, which is
> probably UDP/53 falling back to TCP/53.
>
> --
> P Vixie
>
>

---

From: Paul Vixie <[email-masked]>
Date: Wed, 22 Aug 2018 11:48:54 -0700

Ted Lemon wrote:
> options are architecturally good.   People have often used the DHC
> working group as a way to skate by due diligence on architectural
> considerations; this was considered to be a problem even before I was
> chair, and we burned a lot of time evaluating bad ideas before we
> decided not to be the place where new work on DHCP options is done by
> default.   If a DHCP option were to be entertained, this WG, the dprive
> WG or the DoH WG would be where it would have to happen, not because the
> DHC working group is freezing new features, but because it's not in
> their charter.

you, as an author of two implementations as a former DHC WG chair, have 
said that new features should not be added to DHCP because 
authentication. while i disagree, i recognize that your voice has more 
credibility in the DHCP space than mine does, and i'm ready to give up 
rather than actually fight and lose the battle.

> That said, you responded to a message where I talked about what I think
> we ought to do to move forward by saying that moving forward is
> impossible other than by just adding a hack somewhere.   I don't think
> that's true, and in fact I'm feeling like I need to write up a threat
> analysis because even though it's not something that I want to work on,
> it sounds like most people assume it's impossible and I'm just
> suggesting it as a roadblock, and the people who get that it's necessary
> don't seem to be any more enthusiastic about doing it than I am.   I'd
> appreciate it if, when I've written that analysis, you could contribute
> to it, but I'll understand if you don't have time or don't think it's
> worthwhile.

my own experience as a widely unread author is that i have to keep 
things short or people will refile/delete them, no matter how 
meritorious or relevant (or even pithy and clever) the writing was.

-- 
P Vixie