Subject: [Doh] Request for the DOH WG to adopt draft-hoffman-resolver-associated-doh

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Jan 2019 00:25:55 +0000

Greetings again after a long time. The still-alive DOH WG did not meet at IETF 103. However, I did a short presentation on "Associating a DoH Server with a Resolver" (https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/) at the DNSOP WG. The presentation ended with the question of whether the draft should be taken up in a WG, and if so, where. Since then, there has been some off-list discussion that kinda ended up as "first see if the DOH WG wants to take it up".

People from a few browser vendors have expressed unofficial interest in implementing at least parts of it if it gets standardized, so it seems like a good idea to try to standardize it. There is still a reasonable amount of work to be done in the document itself, and it certainly needs input from both browser and DNS folks.

So, does this WG want to adopt this as a work item?

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Jan 2019 01:07:19 +0000

> On 16 Jan 2019, at 00:25, Paul Hoffman <[email-masked]> wrote:
> 

I think the WG should adopt this.

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 16 Jan 2019 08:52:18 +0100

Moin!

> I think the WG should adopt this.
+1

I wonder if we should extend it to also find DoT servers.

On the top of page 3 I think you mean /etc/resolv.conf and not 
/etc/named.conf.

So long
-Ralf
—--
Ralf Weber

---

From: "A. Schulze" <[email-masked]>
Date: Wed, 16 Jan 2019 19:16:14 +0100

> So, does this WG want to adopt this as a work item?

Hello,

adopt "DoH Servers by TXT" using unbound is fairly simple.
Maybe someone could verify that config.

unbound.conf:
	# option 1:
	# resolver that understands this protocol but has no associated DoH server
	server:
	 local-data: 'resolver-associated-doh.arpa. TXT ""'

	# option 2:
	# resolver that understands this protocol and has one associated DoH server
	server:
	 local-data: 'resolver-associated-doh.arpa. TXT "https://doh.example/"'

	# option 3:
	# resolver that understands this protocol and has multiple associated DoH server
	server:
	 local-data: 'resolver-associated-doh.arpa. TXT "https://doh01.example/"'
	 local-data: 'resolver-associated-doh.arpa. TXT "https://doh02.example/"'

The second suggestion "DoH Servers by Addresses" isn't attractive to me.
Getting a certificate for an IP isn't common these days.

https://IPADDRESSGOESHERE/ -> Ask your favorite CA to issue a certificate for "IPADDRESSGOESHERE"...

also: 
 * https://[2001:db8::53]/ -> Address in []
 * Certificate SAN Entry   -> Address without []
can this work with IPv6? I simply never tried that...

I agree with Ralf on defining something similar for DoT, too

Andreas

---

From: Ben Schwartz <[email-masked]>
Date: Wed, 16 Jan 2019 13:28:03 -0500

DNS over TLS already supports a way for clients to upgrade from unencrypted
DNS, by probing port 853 on the server's IP address.  I presume that's why
DNS over TLS discovery was not mentioned in this draft.  Is probing port
853 sufficient for your use case?

On Wed, Jan 16, 2019 at 1:17 PM A. Schulze <[email-masked]> wrote:

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

---

From: Jim Reid <[email-masked]>
Date: Wed, 16 Jan 2019 18:29:44 +0000

> On 16 Jan 2019, at 07:52, Ralf Weber <[email-masked]> wrote:
> 

IMO that’s something for the dprive WG to decide.

---

From: "A. Schulze" <[email-masked]>
Date: Wed, 16 Jan 2019 19:45:36 +0100

Am 16.01.19 um 19:28 schrieb Ben Schwartz:
> DNS over TLS already supports a way for clients to upgrade from unencrypted DNS, by probing port 853 on the server's IP address.  I presume that's why DNS over TLS discovery was not mentioned in this draft.  Is probing port 853 sufficient for your use case?

Ah! right!
port probing is _the_ obvious option I failed to see.
A short sentence in the spec shouldn't hurt...

Andreas

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 16 Jan 2019 20:43:55 +0100

Moin!

> 853 sufficient for your use case?
Well the performance characteristics for DNS over UDP and DNS over TLS 
or HTTP are different, so it would be good to have different platforms 
for these.

Also to answer Jim Reid I thought I was answering on dnsop and not doh 
(wasn’t sufficiently caffeinated ;-) which is why I brought up DoT. I 
really don’t care to much which working group does the work as long as 
it is done and I’ll do my best to contribute.

So long
-Ralf
—--
Ralf Weber

---

From: Martin Thomson <[email-masked]>
Date: Thu, 17 Jan 2019 08:29:01 +1100

On Wed, Jan 16, 2019, at 11:25, Paul Hoffman wrote:
> People from a few browser vendors have expressed unofficial interest in 
> implementing at least parts of it if it gets standardized, so it seems 
> like a good idea to try to standardize it. There is still a reasonable 
> amount of work to be done in the document itself, and it certainly needs 
> input from both browser and DNS folks.

What happened to DRIU?  It seemed like there was an effort to work on the problem more generally.  But I see the DoT comment down-thread and wonder whether this is the right place for doing this sort of work.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 16 Jan 2019 22:32:06 +0000

On Jan 16, 2019, at 1:29 PM, Martin Thomson <[email-masked]> wrote:
> What happened to DRIU?  It seemed like there was an effort to work on the problem more generally.  

There was little interest in anything other than this part.

> But I see the DoT comment down-thread and wonder whether this is the right place for doing this sort of work.

DPRIVE is (sadly very slowly) working on draft-ietf-dprive-bcp-op, where DoT discovery would fit just fine.

--Paul

---

From: "Winfield, Alister" <[email-masked]>
Date: Thu, 17 Jan 2019 10:18:20 +0000

I'm curious did any of those browsers writers say anything about how this would be implemented?

My guesses are:

As a way that local defined DNS servers can offer DoH service ?
As a way to simplify configuration of DoH ?
Something else ?

Or, it's too soon and we can/should make suggestions as to the intent here.

(please forgive me if this has been asked before)

Alister Winfield

On 16/01/2019, 21:29, "Doh on behalf of Martin Thomson" <[email-masked] on behalf of [email-masked]> wrote:

    _______________________________________________
    Doh mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/doh
    --------------------------------------------------------------------
    This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
    --------------------------------------------------------------------

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

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

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 17 Jan 2019 15:01:30 -0500

> Or, it's too soon and we can/should make suggestions as to the intent here.

Previously [1] on this list, a Google employee who works on Chrome
described a use case relevant to Chrome.  Does this answer your question?

[1] https://mailarchive.ietf.org/arch/msg/doh/37zSj-gLYhuHTnFhMb01Yfaixbg

> On 16/01/2019, 21:29, "Doh on behalf of Martin Thomson" <
> [email-masked] on behalf of [email-masked]> wrote:
>
>     What happened to DRIU?  It seemed like there was an effort to work on
> the problem more generally.  But I see the DoT comment down-thread and
> wonder whether this is the right place for doing this sort of work.
>
>     This email is from an external source. Please do not open attachments
> or click links from an unknown or suspicious origin. Phishing attempts can
> be reported by sending them to [email-masked] as attachments. Thank you
> Information in this email including any attachments may be privileged,
> confidential and is intended exclusively for the addressee. The views
> expressed may not be official policy, but the personal views of the
> originator. If you have received it in error, please notify the sender by
> return e-mail and delete it from your system. You should not reproduce,
> distribute, store, retransmit, use or disclose its contents to anyone.
> Please note we reserve the right to monitor all e-mail communication
> through our internal and external networks. SKY and the SKY marks are
> trademarks of Sky Limited and Sky International AG and are used under
> licence.
>
> Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited
> (Registration No. 2067075), Sky Subscribers Services Limited (Registration
> No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or
> indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the
> companies mentioned in this paragraph are incorporated in England and Wales
> and share the same registered office at Grant Way, Isleworth, Middlesex TW7
> 5QD

---

From: "John Dickinson" <[email-masked]>
Date: Tue, 22 Jan 2019 11:58:33 +0000

> DPRIVE is (sadly very slowly) working on draft-ietf-dprive-bcp-op, where DoT discovery would fit just fine.

I don’t think so. The BCP is Informational, I see server discovery (requiring extensions to the protocol) as well out of scope for the BCP.

As mentioned by Ben, for opportunistic DoT port 853 can be probed, but there is still no DNS or DHCP solution for Strict DoT (i.e. securely obtaining the authentication domain name).

My understanding of this draft is that it provides only an ‘opportunistic’ discovery mechanism for DoH where the resulting URI template cannot be DNSSEC validated by the system resolver or the requesting application/browser. If that is the case the resulting HTTPS connection _could_ have been re-directed and so I think that should be spelt out more clearly. For example, I think that at least the title should be something more like ‘Associating a DoH Server with a Resolver for Opportunistic DoH’.

Other comments:

I find this draft extremely difficult to read. For example, I am unable to easily parse Section 1, Para. 2, Sentence 1:
   “There is a use case for browsers and web applications to want the DNS
   recursive resolver(s) configured in the operating system to use DoH
   for DNS resolution instead of normal DNS, but to do so to at a DoH
   server specified by the configured resolver.”

I find the rest of the Introduction just as difficult to read.

Please add SUDN to the Terminology section and to the next DNS Terminology -bis draft.

Section 2.1
   “the zone resolver-associated-doh.arpa is
   not actually delegated and never will be.”

   So it can never be DNSSEC signed unless you use a local trust anchor.

Section 2.2
   “To find the DoH servers associated with a resolver, the client sends
   a query to

   https://IPADDRESSGOESHERE/.well-known/doh-servers-associated/”

   Need to make it clear that this is a DoH query not a regular “http query”

Section 3 makes no mention of the fact that the OS stub resolver typically has more than 1 resolver configured.

Section 4
   “That wording might say
   something like "DoH server associated with my current resolver" (or
   "servidor DoH asociado con mi resolucion actual" or "serveur DoH
   associe a mon resolveur actuel”).”

   Is this intended to be read only configuration? It doesn’t sound like a configuration item for a User to edit.

I do not think this draft should be adopted until a separate use cases document is written (I am happy to help write it).

regards
John

John Dickinson

https://sinodun.com

Sinodun Internet Technologies Ltd.
Magdalen Centre
Oxford Science Park
Robert Robinson Avenue
Oxford OX4 4GA
U.K.

---

From: "Winfield, Alister" <[email-masked]>
Date: Tue, 22 Jan 2019 12:15:26 +0000

Section 2.1

Instead of this how about putting the information in the reverse zone for the resolver. For example
If my resolver is a.b.c.d then you could put TXT records in the reverse..

d.c.b.a.in-addr.arpa. TXT doh:https://atrusted.example.com/resolve

This is delegated and could be DNSSEC signed.

--
Alister Winfield.

---

From: Jim Reid <[email-masked]>
Date: Tue, 22 Jan 2019 12:50:07 +0000

On 22 Jan 2019, at 12:15, Winfield, Alister <Alister.Winfield=[email-masked]> wrote:
> 
> how about putting the information in the reverse zone for the resolver.
>  ... This is delegated and could be DNSSEC signed.

It won't work for RFC1918 address space.

The bootstrapping problem isn’t solved either. Presumably you’d still be relying on DHCP or something equally insecure to get the IP addresses of the resolving servers.

If a stub resolver gets configured in some other way -- editing /etc/resolv.conf for instance -- that might as well include whatever voodoo is needed for trusted DoH or DoT servers.

And what if that reverse zone isn’t signed? 

Then there are the issues when that zone isn’t managed by the same entity which manages the corresponding forward zone. This is quite common. For example, if I was a Sky customer I very much doubt I’d be able to add/remove/replace one of these hypothetical RRs in whatever Sky reverse zone happens to be “hosting” the IP address of my DoH server today. And if/when I reconnect to your net and get a different IP address, what happens to the old TXT record?

> If my resolver is a.b.c.d then you could put TXT records in the reverse..

That’s a Bad Idea. TXT records are already overloaded (abused?) for all sorts of things. A discrete RRtype would be better. Assuming this suggestion got picked up.

---

From: "Winfield, Alister" <[email-masked]>
Date: Tue, 22 Jan 2019 14:04:44 +0000

I agree just looking at where information 'could' reside use available information and be signed using existing mechanisms. Note, I hate TXT too, NAPTR (+ SRV)  is closest to the requirement in the existing RR types but even that isn't perfect.

Issues this needs to show:
The security of the discovery mechanism,
How a discovered DOH end-point can be trusted (This is related to what the end-user believes is required to trust the TRR. Clearly some trust their ISP others would trust Google yet more would only trust their corporate DNS service)

Is there anywhere thoughts on how to define 'trust' and how that is published, audited, etc especially when you consider this form of discovery of a DOH capability?

A.

On 22/01/2019, 12:50, "Jim Reid" <[email-masked]> wrote:

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 22 Jan 2019 16:11:20 +0000

On Jan 22, 2019, at 3:58 AM, John Dickinson <[email-masked]> wrote:
> I don’t think so. The BCP is Informational,

As a process note, BCPs are standards, not Informational. 

> I see server discovery (requiring extensions to the protocol) as well out of scope for the BCP.

For that, I agree. For DoT, "try it and see" works just fine.

> As mentioned by Ben, for opportunistic DoT port 853 can be probed, but there is still no DNS or DHCP solution for Strict DoT (i.e. securely obtaining the authentication domain name).

Agree. There has been little interest in this so far.

> My understanding of this draft is that it provides only an ‘opportunistic’ discovery mechanism for DoH where the resulting URI template cannot be DNSSEC validated by the system resolver or the requesting application/browser. If that is the case the resulting HTTPS connection _could_ have been re-directed and so I think that should be spelt out more clearly. 

Good point, will do.

> For example, I think that at least the title should be something more like ‘Associating a DoH Server with a Resolver for Opportunistic DoH’.

I would push back on this change because "DoH Servers by TXT" is opportunistic while "DoH Servers by Addresses" is not.

>   Is this intended to be read only configuration? It doesn’t sound like a configuration item for a User to edit.

The purpose of having a WG review the draft is to make it easier to read. All the above seem like good changes.

> I do not think this draft should be adopted until a separate use cases document is written (I am happy to help write it).

We disagree here. In which WG has the separate use cases document being finished before the protocol started worked out well?

--Paul Hoffman

---

From: "John Dickinson" <[email-masked]>
Date: Tue, 22 Jan 2019 17:08:32 +0000

> As a process note, BCPs are standards, not Informational.

OK, my bad.

> I would push back on this change because "DoH Servers by TXT" is opportunistic while "DoH Servers by Addresses" is not.

As you mention in Section 8. This is only true if the application _knows_ how the OS resolver was configured or if the lookup of resolver-addresses.arpa was DNSSEC validated and the application _knows_ it was DNSSEC validated.

> We disagree here. In which WG has the separate use cases document being finished before the protocol started worked out well?

Well it would be good practice especially since we are trying to bring together DNS and HTTP folks. However, I take your point so I guess I would be happy if the use cases you are considering were very explicit and more clearly described in this draft.

regards
John

John Dickinson

https://sinodun.com

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 23 Jan 2019 08:25:37 +0100 (CET)

> So, does this WG want to adopt this as a work item?

Disclaimer: I used to work for a browser company but I no longer do. I never 
spoke for them anyway.

For me, one of the key elements and features with DoH is that I as a user have 
picked a DNS provider I decide to trust. Be it a global CDN provider or my own 
cloud instance. Any other way, with the ISP or my local network admins telling 
me what server to use, is a major setback in my view.

All forms of opportunistic DoH will make it no better than opportunistic DoT, 
which ultimately will fail to protect my privacy.

At the same time I of course appreciate that there's a problem/challenge here 
with figuring out what DoH server to use and how to even find out that there 
is one offered. If I don't know any servers, getting one or a few suggestions 
might help. For this, this spec offers ways and I'm for the working group 
adopting this.

-- 

  / daniel.haxx.se

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 23 Jan 2019 09:18:42 +0100

Moin!

On 23 Jan 2019, at 8:25, Daniel Stenberg wrote:

> For me, one of the key elements and features with DoH is that I as a 
> user have picked a DNS provider I decide to trust.
That is a decision maybe you or me can take as an informed user with 
knowledge of how networks work. Most users and I’m using all of my 
wider family that I support technically as an example could not make 
such a decision. Sure they could click somewhere like they clicked 
ignore cert or enhance your computer multiple times which lead to tons 
of work on my side. This is why I’d like only informed users to make 
that change and let the ISP or network admin running DNS enhance their 
security by pointing them to DoH server.

> Be it a global CDN provider or my own cloud instance.
Well if you run your own DNS instance you soon find out that your Web 
performance especially video is bad, when you are not near your DNS 
server, as none of the big CDN companies will look at the client subnet 
extension you send.

> Any other way, with the ISP or my local network admins telling me what 
> server to use, is a major setback in my view.
>
> All forms of opportunistic DoH will make it no better than 
> opportunistic DoT, which ultimately will fail to protect my privacy.
Well you can protect your privacy today by manually changing you DNS/DoH 
provider already. So the use case described in here is not for you, but 
instead for those that can not make these informed changes.

So long
-Ralf
—--
Ralf Weber

---

From: Tony Finch <[email-masked]>
Date: Wed, 23 Jan 2019 13:23:41 +0000

> me what server to use, is a major setback in my view.

As a University DNS admin, I provide DoH to my users so that they can do
interesting things with it. I'm not going to provide DoH to the world
because it would cost too much effort. And people on our network
ultimately have to use my servers because of all our private names and
addresses. I'm not against them using other servers for off-site names
(after all they can usually just use their mobile provider instead) but
there should at least be a way for their device to automatically locate a
local DNS server with a transport it likes.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
each generation is responsible for the fate of our planet

---

From: Daniel Stenberg <[email-masked]>
Date: Wed, 23 Jan 2019 15:16:53 +0100 (CET)

On Wed, 23 Jan 2019, Tony Finch wrote:

> I'm not against them using other servers for off-site names (after all they 
> can usually just use their mobile provider instead) but there should at 
> least be a way for their device to automatically locate a local DNS server 
> with a transport it likes.

In this regard it is truly unfortunate that a user (application) can't tell if 
name is "local" or "remote" or perhaps which server it should ask for what 
names.

While you want your users to use that local server that you announce to them, 
when I go to my coffee shop or visit a friend of mine I'd rather *not* use 
whatever local server they advertise...

Right now the only way a user can use both local private names as well as 
remote names is by telling one of the resolvers *all* names and hope that it 
fails for the one set it doesn't know of so that the client can switch over 
and use the other server for those names. Not ideal, for privacy reasons and 
more.

-- 

  / daniel.haxx.se

---

From: bert hubert <[email-masked]>
Date: Wed, 23 Jan 2019 15:37:14 +0100

> 853 sufficient for your use case?

With my "large scale internet service provider constituency" hat on, a major
problem for them is that many deployed CPEs announce themselves as
nameserver. So over DHCP they will tell clients to use 192.168.1.1 for DNS.

This leads opportunistic DNS over TLS clients to probe the modem/router/CPE
for TLS support.  For many reasons, CPEs are hard to change substantially,
so it is not that easy to add 853 proxying or an actual DoT server on these
boxes.

So service providers would love to be able to configure a DoT server that
lives on a different IP address than the regularly configured plaintext
nameserver.

	Bert

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 23 Jan 2019 15:39:45 +0100 (CET)

> Il 23 gennaio 2019 alle 8.25 Daniel Stenberg <[email-masked]> ha scritto:
> 

This could be true for you and me, but average users have no idea of what the DNS is - they only make one choice, they pick an *ISP* that they decide to trust. They pay to get "Internet access" from that company and expect that company to provide all it takes for "the Internet to work", including DNS resolution, without them having to do anything; this has been the default situation for the last 20 years at least.

So it's fine if smarter users make changes to this default and pick a DNS provider different from their connectivity provider, and it's fine to empower them to do so, but it's not fine to break the way the Internet normally works for most people, which includes an automated and effortless mechanism to get the DNS resolution service from the ISP when connecting to the network.

Regards,
-- 

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

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Jan 2019 13:16:30 -0500

Okay, but for that use case, why not DoT rather than DoH?   What's the
advantage of DoH in this use case?

On Wed, Jan 23, 2019 at 9:39 AM Vittorio Bertola <vittorio.bertola=
[email-masked]> wrote:

> user have
> This could be true for you and me, but average users have no idea of what
> the DNS is - they only make one choice, they pick an *ISP* that they decide
> to trust. They pay to get "Internet access" from that company and expect
> that company to provide all it takes for "the Internet to work", including
> DNS resolution, without them having to do anything; this has been the
> default situation for the last 20 years at least.
>
> So it's fine if smarter users make changes to this default and pick a DNS
> provider different from their connectivity provider, and it's fine to
> empower them to do so, but it's not fine to break the way the Internet
> normally works for most people, which includes an automated and effortless
> mechanism to get the DNS resolution service from the ISP when connecting to
> the network.
>
> Regards,
> --
>

---

From: bert hubert <[email-masked]>
Date: Wed, 23 Jan 2019 19:23:25 +0100

> So, does this WG want to adopt this as a work item?

Yes. My reasoning is as follows. Even though it is a challenging subject,
if we don't do it bad things will happen. As long as there is no way to
associate a network with an encrypted DNS provider (DoH in this case), we
can not rebut the argument "we simply HAVE to centralize the DNS on this
cloud provider because there is no alternative".

Regardless of what we think about the desireability of centralized or
decentralized DNS, it is never good if there are no options.

So I hope we can give this a very hard think to see what we can come up
with.

To stimulate the discussion a bit, it turns out browsers already contain a
list of providers they are willing to trust. It may be that the solution for
provisioning DoH securely also involves having a list of providers who are
allowed to provision DoH.

The existing list of trusted parties that can (not) be trusted is of course
the list of trusted certificate authorities.

	Bert

---

From: Peter Saint-Andre <[email-masked]>
Date: Wed, 23 Jan 2019 12:16:09 -0700

On 1/23/19 12:25 AM, Daniel Stenberg wrote:
> Disclaimer: I used to work for a browser company but I no longer do. I
> never spoke for them anyway.
> 

You are in a small minority. :-) Very few users will ever change their
settings.

> Be it a global CDN
> provider or my own cloud instance. Any other way, with the ISP or my
> local network admins telling me what server to use, is a major setback
> in my view.

The local network admins in your enterprise might want to have more
control, which seems OK to me because, depending on your company's
policies, they might own or have effective control over your device
(however, your user agent might want to override the suggestions it
receives).

> All forms of opportunistic DoH will make it no better than opportunistic
> DoT, which ultimately will fail to protect my privacy.
> 
> At the same time I of course appreciate that there's a problem/challenge
> here with figuring out what DoH server to use and how to even find out
> that there is one offered. If I don't know any servers, getting one or a
> few suggestions might help. For this, this spec offers ways and I'm for
> the working group adopting this.

+1 to adoption.

Peter

---

From: Daniel Stenberg <[email-masked]>
Date: Mon, 28 Jan 2019 09:05:07 +0100 (CET)

On Wed, 23 Jan 2019, Vittorio Bertola wrote:

> to trust.

I don't know a single ordinary person who selected their ISP based on their 
privacy stance for DNS queries. The people I know pick ISP primarily based on 
availability, price, bandwidth and technology.

I actually think rather few people trust their ISP, and I think history would 
give them right since so many ISPs have violated their users' privacy and data 
through the years.

-- 

  / daniel.haxx.se

---

From: "Winfield, Alister" <[email-masked]>
Date: Mon, 28 Jan 2019 09:58:17 +0000

I happen to find it harder to trust a company where there is no contract and the company is not operating under local laws that I know and understand. Others with less trust of local laws, regulations and governments would feel rather differently. At work I'll take the local resolvers over everything else because I know they will do what they can to avoid malware inside the network (eg blocking C&C domains).

So can we be more nuanced in the meaning of trusted and accept both viewpoints.

This exchange is why I think the whole area is missing concepts:

a) Defining trust and privacy in general terms. The BCP draft has some of this but it's likely that there is more to do to cover every angle.
b) Somehow securely advertising what types of trust and privacy your resolver is built to provide. Here we are very light and it could be built into the discovery mechanism or perhaps not ?
c) Auditing and its related actions on failure to uphold promises made in (b). Here be dragons, the problem is avoiding a central authority that charges and allowing anyone to setup a DNS TRR perhaps akin to self-signed certs in the way that the client can handle 'trust'. Perhaps a notary solution is better in that it allows a user to define who they trust and that trusted entity can then accept or deny resolvers.

Remember, the autodetection concept is for those where using local DNS is a non-issue or is required. Yes for those who are more focused on the transport security the way you get that DNS resolver IP is suspect but that is an interesting challenge for the protocols involved (DHCP, PPPoE etc).

--
Alister Winfield.

On 28/01/2019, 08:05, "Doh on behalf of Daniel Stenberg" <[email-masked] on behalf of [email-masked]> wrote:

    --

      / daniel.haxx.se

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 28 Jan 2019 10:03:00 +0000

On adopting the draft - I think it makes sense that it be
adopted somewhere but share concerns mentioned before that
it'd be better to take a more holistic view of DNS server
discovery so am not sure if the DoH WG is the right venue.
Even if DoT discovery by probing port 853 is possible, in
some networks 853 is blocked, so some DoT servers are on
443 and hence need to be discovered. Later on, I'd not be
surprised if someone wants a way to do and discover DNS
over QUIC. So while the RAD RR proposed here may be the
right answer, I think that should emerge for a discussion
that's broader than just DoH. (Apologies if that happened
and was completed at the driu discussion, but even if so,
re-doing that discussion more formally/openly would seem
to be needed.)

Meanwhile, I got tempted into the discussion by the exchange
below...

Cheers,
S.

On 28/01/2019 08:05, Daniel Stenberg wrote:
>> This could be true for you and me, but average users have no idea of
>> what the DNS is - they only make one choice, they pick an *ISP* that
>> they decide to trust.
> 
> I don't know a single ordinary person who selected their ISP based on
> their privacy stance for DNS queries. The people I know pick ISP
> primarily based on availability, price, bandwidth and technology.

I do know a handful of people who select their ISP based on their
perception of the overall tech/privacy attitude of the ISP. But yes,
that's v. rare afaik.

A similar thing is true wrt browser selection though - I know a few
people who pick and choose for various reasons, but IIUC most do not,
they just take what their OS provides.

> I actually think rather few people trust their ISP, and I think history
> would give them right since so many ISPs have violated their users'
> privacy and data through the years.
> 

I suspect that differs from place to place in the world to some
extent. I think it's true that people where I'm from (.ie) used to
have a fairly high level of confidence that the then-encumbent
telco wasn't going to try abuse their data for profit. (There were
other downsides to dealing with a govt-owned badly-run telco, but
that wasn't one of them;-) That hasn't entirely gone despite a
number of ownership changes, but it does seem fair to say that
that confidence has been eroded quite a bit here - that company
is now just one among a bunch of similar entities, mostly picked
for price etc as you note above.

My conclusion is that people do not select their DNS recursive
in any meaningful sense.

Cheers,
S.

---

From: "John Dickinson" <[email-masked]>
Date: Mon, 28 Jan 2019 10:18:36 +0000

On 28 Jan 2019, at 8:05, Daniel Stenberg wrote:

>> This could be true for you and me, but average users have no idea of what the DNS is - they only make one choice, they pick an *ISP* that they decide to trust.
>
> I don't know a single ordinary person who selected their ISP based on their privacy stance for DNS queries. The people I know pick ISP primarily based on availability, price, bandwidth and technology.

I imagine that the “ordinary person” might well be influenced by consumer advice services and reviews in computing literature. These groups might well suggest ISPs with good privacy policies.

>
> I actually think rather few people trust their ISP, and I think history would give them right since so many ISPs have violated their users' privacy and data through the years.

I think this depends on where in the world you are.

regards
John

John Dickinson

https://sinodun.com

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 29 Jan 2019 15:48:50 +0100

On Wed, Jan 16, 2019 at 12:25:55AM +0000,
 Paul Hoffman <[email-masked]> wrote 
 a message of 121 lines which said:

> I did a short presentation on "Associating a DoH Server with a
> Resolver"
> (https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/)
> at the DNSOP WG. The presentation ended with the question of whether
> the draft should be taken up in a WG, and if so, where.

I tend to say Yes, because it is an interesting and useful
subject. However, I also tend to agree with Stephen Farrell that a
general "DNS resolver discovery solution", not limited to DoH, would
be a good idea.

In the current draft, I have a big concern about the idea of an
application (for instance the Web browser) having a specific DNS
resolver (section 5 of draft -07), different from the rest of the
applications on the same machine. It will be a nightmare to debug DNS
issues with such a setup. We cannot prevent people for doing bad
choices like this one but we should not condone it in a RFC. IMHO, the
correct setup is a shared DoH client, running on the local machine
(stubby, systemd-resolve, etc) or on the CPE.

[This is a purely technical issue, different for the more political
one raised by Bert Hubert.]

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 29 Jan 2019 15:55:07 +0100

On Wed, Jan 16, 2019 at 07:16:14PM +0100,
 A. Schulze <[email-masked]> wrote 

> can this work with IPv6? I simply never tried that...

<https://[2606:4700:4700::1111]/> works for me (Firefox 60.4.0)

and the certificate includes SANs:

DNS Name: cloudflare-dns.com
DNS Name: *.cloudflare-dns.com
DNS Name: one.one.one.one
IP Address: 1.1.1.1
IP Address: 1.0.0.1
IP Address: 162.159.132.53
IP Address: 2606:4700:4700::1111
IP Address: 2606:4700:4700::1001

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 29 Jan 2019 15:00:17 +0000

On Jan 29, 2019, at 6:48 AM, Stephane Bortzmeyer <[email-masked]> wrote:
> applications on the same machine.

If you have this concern, you need to bring it up with the browser vendors, not with this WG. I have been informally told that both Firefox and Chrome have them (but I have not checked).

> It will be a nightmare to debug DNS
> choices like this one but we should not condone it in a RFC.

You first have to have the discussion of whether or not this is a bad choice. There will likely be differing opinions. That is, I suspect that the browser vendors didn't spend the time and effort to put them in just for fun: they felt a need. I totally understand that this will cause debugging to be more difficult, but that is true for a lot of things added in modern browsers.

> IMHO, the

...and yet there is no indication that such a thing exists today, nor is planned by any of the OS vendors.

(Side note: given how crappy CPE software is consistently shown to be, I am horrified that you suggest to put anything there in the same message where you talk about "nightmare to debug".)

> one raised by Bert Hubert.]

It has the same effect, however. If a user is smart enough to have an opinion like "I trust my {browser|OS} vendor more than my {OS|browser} vendor", some will pick one and some will pick the other.

--Paul Hoffman

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 29 Jan 2019 16:06:40 +0100

On Wed, Jan 23, 2019 at 03:39:45PM +0100,
 Vittorio Bertola <vittorio.bertola=[email-masked]> wrote 
 a message of 22 lines which said:

> they only make one choice, they pick an *ISP* that they decide to
> trust. They pay to get "Internet access" from that company and
> expect that company to provide all it takes for "the Internet to
> work", including DNS resolution, without them having to do anything;
> this has been the default situation for the last 20 years at least.

This is not how the Internet works. 20 years ago, may be this was true
but, today, users "trust" (not an informed trust) a lot of
intermediaries. For instance, if they use Android, a lot of choices
are made by Google, not by the ISP.

Which means that changes like DoH could be carried by other actors
than the user or the ISP. If people buy CPEs with a pre-configured DoH
client, they could use DoH even without a specific concern for privacy.

> So it's fine if smarter users make changes to this default and pick
> a DNS provider different from their connectivity provider, and it's
> fine to empower them to do so, but it's not fine to break the way
> the Internet normally works for most people, which includes an
> automated and effortless mechanism to get the DNS resolution service
> from the ISP when connecting to the network.

I don't understand this objection. Nobody suggested to deprecate DHCP
and its DNS resolver option.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 29 Jan 2019 16:07:20 +0100

On Mon, Jan 28, 2019 at 09:05:07AM +0100,
 Daniel Stenberg <[email-masked]> wrote 
 a message of 22 lines which said:

> I actually think rather few people trust their ISP, and I think
> history would give them right since so many ISPs have violated their
> users' privacy and data through the years.

+1 And this is one of the main goals of DoH, after all.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 29 Jan 2019 16:13:38 +0100

On Tue, Jan 29, 2019 at 03:00:17PM +0000,
 Paul Hoffman <[email-masked]> wrote 
 a message of 40 lines which said:

> If you have this concern, you need to bring it up with the browser
> vendors, not with this WG.

I bring the concern here because the first paragraph of section 5
appears to approve this strategy.

> > IMHO, the correct setup is a shared DoH client, running on the
> > local machine (stubby, systemd-resolve, etc) or on the CPE.
> 

systemd-resolve seems to be used by several OS (I don't like systemd
but this is another issue: the point is that it can be done).

> (Side note: given how crappy CPE software is consistently shown to
> be, I am horrified that you suggest to put anything there in the
> same message where you talk about "nightmare to debug".)

Not all CPEs <https://en.wikipedia.org/wiki/NotAllMen> I use a Turris
Omnia <https://en.wikipedia.org/wiki/Turris_Omnia> at home and this is
exactly the sort of CPE I had in mind.

---

From: Daniel Stenberg <[email-masked]>
Date: Tue, 29 Jan 2019 16:50:41 +0100 (CET)

On Tue, 29 Jan 2019, Stephane Bortzmeyer wrote:

> I have a big concern about the idea of an application (for instance the Web 
> browser) having a specific DNS resolver (section 5 of draft -07), different 
> from the rest of the applications on the same machine.

*That* development has been going on since many years already, totally 
independent of secure DNS, partly due to the lack of proper standard 
asynch/non-blocking APIs. (I maintain one such library.)

A more positive way to look at such independent code is that it allows for 
better innovation and freedom for applications as they're not held back by 
(from their point of view) limited system implementations.

I don't think we, or anyone else, can stop that trend and I don't think we 
should try. I think we should be agnostic to where the implementations lie.

-- 

  / daniel.haxx.se