Subject: [dns-privacy] Trying to understand DNS resolver 'discovery'

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Nov 2019 12:35:13 -0500

This notion of DNS resolver discovery seems very strange to me. There are
three ways in which a DNS resolver can be realistically determined by a
client whether that is in the platform (Windows/OSX/Linux/etc) or the
application.

1) Promiscuous DNS
    The client obtains the information to connect to a resolver either as
part of DHCP configuration or by further interrogation of the local network.

2) Admin/User Configured DNS
    The client obtains the information to connect to a resolver through an
Administrator or User configuration action. This may be inserting an IP
address (8.8.8.8/1.1.1.1/etc) or some form of DNS label.

3) Application/Platform Provider Configuration.
    The application or OS platform can simply ignore user preferences and
choose a DNS provider of its own liking.

This is not an exhaustive enumeration of the possibilities of course. But
please, assure me that we are not the brink of users being faced with pop
ups asking them 'would you like to choose me as your DNS provider'.

Of these three models, I have always considered (1) to be a security hole.
It made some sense in the days when the smallest machine connected to the
Internet was the size of a washing machine and portable computers didn't
exist. But not today.

[As a pragmatic matter, it will continue to be necessary for devices to use
the local network DNS resolver for the purpose of connecting to WiFi in
kiosk type environments. ]

We might well see the third model being imposed by government decree in
some places. Along with the DNSSEC root key to be used for validation.

Yes, there are situations where split DNS has to be considered so that the
device knows that when it is on the employer network it behaves
differently. But I see those as being a subset of VPN config. If Alice
works for example.com, then she can install a signed config file stating
which DNS resolvers and IPSEC (or other VPN) parameters to use on which
networks for which sets of DNS addresses.

So what I see is a requirement for DNS resolver configuration. We already
have rfc6763 to tell us how to get from a DNS label to an Internet service.
Albeit one that presupposes the existence of a resolution mechanism. I
don't see it being problematic to use the local DNS to do this resolution
provided that 1) we have the means to authenticate the connection and 2) we
only use this mechanism once, to perform initial configuration.

DNS resolution service providers do need to change their IP configs from
time to time of course. But there is an expectation that the resolver IP is
stable over very long periods of time. Moving to DNS names for resolvers
does not free us from this expectation in this case.

In my view, choice of a DNS resolver should be an event backed by ceremony
so while I think we can and should insist on DNSSEC authentication for the
resolver[1], there is certainly a potential role for a WebPKI certificate
to establish accountability (i.e. EV). There is also a potential role for
use of rfc3709 (logotypes) to provide a strong security signal during a
one-time configuration operation.

[1]  Even if the local resolver does not support DNSSEC or insists on the
use of an untrusted root, the DPRIV service being connected to can provide
this information as part of the initial handshake.

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Nov 2019 09:51:14 -0800

On Tue, Nov 26, 2019 at 9:35 AM Phillip Hallam-Baker <[email-masked]>
wrote:

> This notion of DNS resolver discovery seems very strange to me.
>

The larger issue (and the one I am interested in finding solutions for) is
that what is configured as a 'resolver', might actually be a 'forwarder'.

I.e. the path is generalized as client -> forwarder* -> resolver (zero or
more forwarders).

Any DNS client, and any DNS server, when communicating, are unable to
distinguish whether the other is (respectively) a resolver or forwarder, or
a client or forwarder.

For the DPRIVE use case, it is hopefully clear that the path from the
client to the (ultimate) resolver, needs to be encrypted in order to
achieve privacy.

However, if the only place the client is able to establish an encrypted
path to is a forwarder, this leave open the possibility that the
forwarder->(forwarder->[...])->resolver might involve one or more
unencrypted connections.

Depending on the network(s) and presence of NAT(s), it may or may not be
possible for the client to communicate directly with the (ultimate, actual)
resolver.

It is also a potential issue in addressing this issue with any
mechanism(s), that intermediate forwarders and the resolver itself, may not
have FQDNs of any sort, may not have NSIDs configured, and may not have
public (globally unique) IP addresses.

So, the 'discovery' can involve any or all of, some naming method (for
things without FQDNs), path discovery, address discovery, and address scope
conflict detection, with the preferred result of client->resolver direct
connection with encrypted transport.

Brian

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Nov 2019 19:04:41 +0100

On Tue, Nov 26, 2019 at 12:35:13PM -0500,
 Phillip Hallam-Baker <[email-masked]> wrote 

> choose a DNS provider of its own liking.

Note that, for free software, there is no real difference between 2)
and 3). Someone can always change the source and recompile. (And there
is of course no real privacy without free software.)

> But please, assure me that we are not the brink of users being faced
> with pop ups asking them 'would you like to choose me as your DNS
> provider'.

Why not? But, anyway, the IETF does not do UI so it's not really our
job.

> Of these three models, I have always considered (1) to be a security

I fully agree. *All* "automatic discovery of the DoH resolver" schemes
are broken by design and I really wonder why people keep suggesting
them.

> So what I see is a requirement for DNS resolver configuration. We
> already have rfc6763 to tell us how to get from a DNS label to an
> Internet service.  Albeit one that presupposes the existence of a
> resolution mechanism. I don't see it being problematic to use the
> local DNS to do this resolution provided that 1) we have the means
> to authenticate the connection and 2) we only use this mechanism
> once, to perform initial configuration.

I agree too. A simple _doh.MYDOMAIN.example/SRV request would
suffice. (Even better, HTTP should support SRV, but I digress...)

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Tue, 26 Nov 2019 19:08:13 +0100

On Tue, Nov 26, 2019 at 09:51:14AM -0800,
 Brian Dickson <[email-masked]> wrote 
 a message of 98 lines which said:

> However, if the only place the client is able to establish an
> encrypted path to is a forwarder, this leave open the possibility
> that the forwarder->(forwarder->[...])->resolver might involve one
> or more unencrypted connections.

I'm not sure I understand the problem. This case is just an instance
of a more general problem "the machine you talk with may betray you
and no amount of cryptography will help here". The resolver can send a
copy of all your requests to the NSA (or its chinese equivalent), or
it could use a forwarder over an unencrypted connection. What's the
difference?

---

From: Brian Dickson <[email-masked]>
Date: Tue, 26 Nov 2019 10:22:26 -0800

> it could use a forwarder over an unencrypted connection. What's the
The difference is whether the problem is fundamentally unsolvable vs a
solvable problem.

Clearly, a resolver which betrays your trust deliberately can't be fixed
with any technology, it's a layer-8 or layer-9 problem.

However, a forwarder chain may not be intentionally insecure, and may only
be the result of naive designs or lack of vendor support.

The resolver at the end of the forwarder chain may actually be trustworthy,
so having a way of talking directly to it, solves the issue.

It also does so in a way that does not adversely affect the DNS ecosystem,
and in fact doesn't adversely affect the resolver itself.

A forwarder (or chain of forwarders, or tree of forwarders rooted at the
resolver) sends every query to the resolver. Connecting directly to the
resolver does not change that load, it merely bypasses middle boxes that
are value-subtract devices.

If anything, DNS resolution should improve, since it would (in theory, at
least) reduce latency, and possibly reduce loss caused by (DNS) application
queueing compared to strict network-level (hardware) queue use.

Brian

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Tue, 26 Nov 2019 13:34:38 -0500

> is of course no real privacy without free software.)

A very small number of people have that ability. It is not possible for the
typical iOS user for example.

>From my perspective, the user is the only valid source of authority. The
user must have control of their environment (unless they are at work and
know that they have surrendered control in return for a consideration).

> Why not? But, anyway, the IETF does not do UI so it's not really our

Modern Web browsers have countless security blunders. Allowing sites to do
pop ups at all was an abomination.

Saying we don't do UI in this case is like saying we don't do security.
Changes to the security configuration should only be initiated by the user.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 08:48:02 +0000

Hi Phillip,

Nice summary, Please see inline

From: dns-privacy <[email-masked]> On Behalf Of Phillip Hallam-Baker
Sent: Tuesday, November 26, 2019 11:05 PM
To: [email-masked]
Subject: [dns-privacy] Trying to understand DNS resolver 'discovery'

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

________________________________
This notion of DNS resolver discovery seems very strange to me. There are three ways in which a DNS resolver can be realistically determined by a client whether that is in the platform (Windows/OSX/Linux/etc) or the application.

1) Promiscuous DNS
    The client obtains the information to connect to a resolver either as part of DHCP configuration or by further interrogation of the local network.

[TR] DHCP and NDP can be spoofed, and I don’t think secure neighbor discovery is deployed. https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05 proposes a mechanism to securely bootstrap endpoints to discover and authenticate DoT/DoH servers provided by a local network.

2) Admin/User Configured DNS
    The client obtains the information to connect to a resolver through an Administrator or User configuration action. This may be inserting an IP address (8.8.8.8/1.1.1.1/etc<http://8.8.8.8/1.1.1.1/etc>) or some form of DNS label.

3) Application/Platform Provider Configuration.
    The application or OS platform can simply ignore user preferences and choose a DNS provider of its own liking.

This is not an exhaustive enumeration of the possibilities of course. But please, assure me that we are not the brink of users being faced with pop ups asking them 'would you like to choose me as your DNS provider'.

Of these three models, I have always considered (1) to be a security hole. It made some sense in the days when the smallest machine connected to the Internet was the size of a washing machine and portable computers didn't exist. But not today.

[TR] IoT devices may also want to use DoT/DoH servers for both privacy and security.

[As a pragmatic matter, it will continue to be necessary for devices to use the local network DNS resolver for the purpose of connecting to WiFi in kiosk type environments. ]

We might well see the third model being imposed by government decree in some places. Along with the DNSSEC root key to be used for validation.

Yes, there are situations where split DNS has to be considered so that the device knows that when it is on the employer network it behaves differently. But I see those as being a subset of VPN config. If Alice works for example.com<http://example.com>, then she can install a signed config file stating which DNS resolvers and IPSEC (or other VPN) parameters to use on which networks for which sets of DNS addresses.

[TR] Yup, it is not a problem for IT managed or MDM devices but a challenge for BYOD devices.

Cheers,
-Tiru

So what I see is a requirement for DNS resolver configuration. We already have rfc6763 to tell us how to get from a DNS label to an Internet service.. Albeit one that presupposes the existence of a resolution mechanism. I don't see it being problematic to use the local DNS to do this resolution provided that 1) we have the means to authenticate the connection and 2) we only use this mechanism once, to perform initial configuration.

DNS resolution service providers do need to change their IP configs from time to time of course. But there is an expectation that the resolver IP is stable over very long periods of time. Moving to DNS names for resolvers does not free us from this expectation in this case.

In my view, choice of a DNS resolver should be an event backed by ceremony so while I think we can and should insist on DNSSEC authentication for the resolver[1], there is certainly a potential role for a WebPKI certificate to establish accountability (i.e. EV). There is also a potential role for use of rfc3709 (logotypes) to provide a strong security signal during a one-time configuration operation.

[1]  Even if the local resolver does not support DNSSEC or insists on the use of an untrusted root, the DPRIV service being connected to can provide this information as part of the initial handshake.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 08:57:42 +0000

Hi Brian,

Yes, the client needs to discover the privacy policy information of both the forwarder and recursive resolvers, and if the DNS messages are encrypted between the forwarder and recursive resolver. Further, the forwarding DNS server can be configured with both primary and secondary resolvers as a backup mechanism to handle primary server failure.

You may want to look into privacy information claim discussed in https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-01#section-6.2.2. It includes the upstream servers privacy claims and if DoT or DoH is used to encrypt the DNS messages exchanged between the local DNS server and recursive resolver.

Cheers,
-Tiru
From: dns-privacy <[email-masked]> On Behalf Of Brian Dickson
Sent: Tuesday, November 26, 2019 11:21 PM
To: Phillip Hallam-Baker <[email-masked]>
Cc: [email-masked]
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

________________________________
On Tue, Nov 26, 2019 at 9:35 AM Phillip Hallam-Baker <[email-masked]<mailto:[email-masked]>> wrote:
This notion of DNS resolver discovery seems very strange to me.

The larger issue (and the one I am interested in finding solutions for) is that what is configured as a 'resolver', might actually be a 'forwarder'.

I.e. the path is generalized as client -> forwarder* -> resolver (zero or more forwarders).

Any DNS client, and any DNS server, when communicating, are unable to distinguish whether the other is (respectively) a resolver or forwarder, or a client or forwarder.

For the DPRIVE use case, it is hopefully clear that the path from the client to the (ultimate) resolver, needs to be encrypted in order to achieve privacy.

However, if the only place the client is able to establish an encrypted path to is a forwarder, this leave open the possibility that the forwarder->(forwarder->[...])->resolver might involve one or more unencrypted connections.

Depending on the network(s) and presence of NAT(s), it may or may not be possible for the client to communicate directly with the (ultimate, actual) resolver.

It is also a potential issue in addressing this issue with any mechanism(s), that intermediate forwarders and the resolver itself, may not have FQDNs of any sort, may not have NSIDs configured, and may not have public (globally unique) IP addresses.

So, the 'discovery' can involve any or all of, some naming method (for things without FQDNs), path discovery, address discovery, and address scope conflict detection, with the preferred result of client->resolver direct connection with encrypted transport.

Brian

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 09:07:15 +0000

> -----Original Message-----
> From: dns-privacy <[email-masked]> On Behalf Of Stephane
> Bortzmeyer
> Sent: Tuesday, November 26, 2019 11:35 PM
> CAUTION: External email. Do not click links or open attachments unless you
> recognize the sender and know the content is safe.
> 
> On Tue, Nov 26, 2019 at 12:35:13PM -0500,  Phillip Hallam-Baker
> <[email-masked]> wrote  a message of 166 lines which said:
> 
> >     The client obtains the information to connect to a resolver
> > through an Administrator or User configuration action. This may be
> > inserting an IP address (8.8.8.8/1.1.1.1/etc) or some form of DNS label.
> >
> >     The application or OS platform can simply ignore user preferences
> > and choose a DNS provider of its own liking.
> 
> Note that, for free software, there is no real difference between 2) and 3).
> Someone can always change the source and recompile. (And there is of
> course no real privacy without free software.)
> 
> Why not? But, anyway, the IETF does not do UI so it's not really our job.
> 
> I fully agree. *All* "automatic discovery of the DoH resolver" schemes are
> broken by design and I really wonder why people keep suggesting them.

Not all discovery mechanisms have security holes, you may want to look into https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05.  The draft discusses procedures to automatically securely bootstrap endpoints to discover and authenticate DoT/DoH servers provided by a local network.  

> > local DNS to do this resolution provided that 1) we have the means to
> > authenticate the connection and 2) we only use this mechanism once, to
> > perform initial configuration.
> 
> I agree too. A simple _doh.MYDOMAIN.example/SRV request would suffice.
> (Even better, HTTP should support SRV, but I digress...)

Yup, DNS-SD should suffice. The service portion for DoT/DoH are defined in https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05#section-6 

-Tiru

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

---

From: Neil Cook <[email-masked]>
Date: Wed, 27 Nov 2019 09:31:55 +0000

> On 26 Nov 2019, at 17:35, Phillip Hallam-Baker <[email-masked]> wrote:
> 
> So what I see is a requirement for DNS resolver configuration. We already have rfc6763 to tell us how to get from a DNS label to an Internet service. Albeit one that presupposes the existence of a resolution mechanism. I don't see it being problematic to use the local DNS to do this resolution provided that 1) we have the means to authenticate the connection and 2) we only use this mechanism once, to perform initial configuration.
> 

How will the connection to the local resolver be authenticated? Also, presumably this mandates the use of DNSSEC by the client?

Neil

---

From: Neil Cook <[email-masked]>
Date: Wed, 27 Nov 2019 10:04:57 +0000

> On 26 Nov 2019, at 18:04, Stephane Bortzmeyer <[email-masked]> wrote:
> 

Resolver discovery schemes allow a client to ask the local resolver to provide information about the resolver, such as DoH info, as well as potentially other information about the resolver. I don’t see why they’re broken by design; yes they add no security properties on top of the (insecure) DHCP mechanism used to contact the resolver in the first place, but how clients use that information is up to them. They may or may not decide to trust that resolver, they may have a preconfigured list of trusted DoH servers, they may use it only to bootstrap connections to other servers, as suggested below. You may for example prefer your _doh.MYDOMAIN.example/SRV request to be sent over an encrypted connection.

Also without a discovery protocol, the only way to use an encrypted DNS connection would be to manually enter it , or use a pre-configured centralised DNS service using the Mozilla model. I’d much rather see all those existing non-encrypted connections moved to encrypted connections (using DoT or DoH) by default - it doesn’t preclude anything else you’ve suggested. It also doesn’t means that users who are depending on services provided by their local resolver (such as malware filtering, parental controls), would continue to be able to make use of them.

Neil

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 14:09:29 +0000

> From: dns-privacy <[email-masked]> On Behalf Of Neil Cook
> Sent: Wednesday, November 27, 2019 3:02 PM
> Albeit one that presupposes the existence of a resolution mechanism. I don't
> see it being problematic to use the local DNS to do this resolution provided
> that 1) we have the means to authenticate the connection and 2) we only
> use this mechanism once, to perform initial configuration.
> >
> 
> How will the connection to the local resolver be authenticated? Also,
> presumably this mandates the use of DNSSEC by the client?

The client can validate the server certificate signed by a CA, and it will work for Enterprise deployments. However, it will be challenging for the DNS forwarder co-located on the home router to get the certificate signed by CA today but may be possible in future with ACME https://tools.ietf.org/html/draft-ietf-acme-ip-08 and IPv6. 

-Tiru

---

From: Neil Cook <[email-masked]>
Date: Wed, 27 Nov 2019 14:17:30 +0000

> On 27 Nov 2019, at 14:09, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
>> 

If the client is connecting to the local resolver in order to bootstrap finding a DoH server, which is what the above proposal says, then it’s talking DNS53 and there’s no authentication. Unless the resolver and client both support DoT, in which case the server is still being contacted via IP address. If the resolver is a forwarder on an RFC1918 IP address, like many/most home routers, then authentication is a non-starter (I don’t see how the above draft helps with that).

So authentication would work in non-enterprise scenarios, assuming both client and resolver/forwarder support DoT, and the resolver/forwarder is not using an RFC1918 address.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 14:22:31 +0000

> Sent: Wednesday, November 27, 2019 3:35 PM
> To: Stephane Bortzmeyer <[email-masked]>
> Cc: [email-masked]; Phillip Hallam-Baker <[email-masked]>
> Resolver discovery schemes allow a client to ask the local resolver to provide
> information about the resolver, such as DoH info, as well as potentially other
> information about the resolver. I don’t see why they’re broken by design;
> yes they add no security properties on top of the (insecure) DHCP
> mechanism used to contact the resolver in the first place, but how clients use
> that information is up to them. They may or may not decide to trust that
> resolver, 

The problem with DHCP is the client has no way to know whether the DoT/DoH server is indeed hosted by the local network or by an attacker. For example, consider a network using Quad9/OpenDNS to perform malware filtering but attacker spoofs the DHCP response to convey the network is using CloudFlare DNS server. Chrome would establish DoH with CloudFlare, and the attack is successful. It is also easy for the attacker to get a domain name, and get the certificate signed by the CA (domain validate certificate).

-Tiru

> they may have a preconfigured list of trusted DoH servers, they
> may use it only to bootstrap connections to other servers, as suggested
> below. You may for example prefer your _doh.MYDOMAIN.example/SRV
> request to be sent over an encrypted connection.
> 
> Also without a discovery protocol, the only way to use an encrypted DNS
> connection would be to manually enter it , or use a pre-configured
> centralised DNS service using the Mozilla model. I’d much rather see all those
> existing non-encrypted connections moved to encrypted connections (using
> DoT or DoH) by default - it doesn’t preclude anything else you’ve suggested.
> It also doesn’t means that users who are depending on services provided by
> their local resolver (such as malware filtering, parental controls), would
> continue to be able to make use of them.
> 
> >> authenticate the connection and 2) we only use this mechanism once,
> >> to perform initial configuration.
> >
> suffice.

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 14:24:21 +0000

> From: Neil Cook <[email-masked]>
> Sent: Wednesday, November 27, 2019 7:48 PM
> To: Konda, Tirumaleswar Reddy <[email-masked]>
> Cc: Phillip Hallam-Baker <[email-masked]>; [email-masked]
> > On 27 Nov 2019, at 14:09, Konda, Tirumaleswar Reddy
> <[email-masked]> wrote:
> >>
> >>> On 26 Nov 2019, at 17:35, Phillip Hallam-Baker
> >>> <[email-masked]>
> >> wrote:
> >>>
> >>> already
> >> Albeit one that presupposes the existence of a resolution mechanism.
> >> I don't see it being problematic to use the local DNS to do this
> >> resolution provided that 1) we have the means to authenticate the
> >> connection and 2) we only use this mechanism once, to perform initial
> configuration.
> >>>
> >>
> > The client can validate the server certificate signed by a CA, and it will work
> for Enterprise deployments. However, it will be challenging for the DNS
> forwarder co-located on the home router to get the certificate signed by CA
> today but may be possible in future with ACME
> https://tools.ietf.org/html/draft-ietf-acme-ip-08 and IPv6.
> >
> 
> If the client is connecting to the local resolver in order to bootstrap finding a
> DoH server, which is what the above proposal says, then it’s talking DNS53
> and there’s no authentication. Unless the resolver and client both support
> DoT, in which case the server is still being contacted via IP address. If the
> resolver is a forwarder on an RFC1918 IP address, like many/most home
> routers, then authentication is a non-starter (I don’t see how the above draft
> helps with that).
> 
> So authentication would work in non-enterprise scenarios, assuming both
> client and resolver/forwarder support DoT, and the resolver/forwarder is not
> using an RFC1918 address.

Yup, we are in the same page.

-Tiru

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Nov 2019 15:28:42 +0100

On Wed, Nov 27, 2019 at 09:07:15AM +0000,
 Konda, Tirumaleswar Reddy <[email-masked]> wrote 
 a message of 72 lines which said:

> > *All* "automatic discovery of the DoH resolver" schemes are broken
> > by design and I really wonder why people keep suggesting them.
> 
> Not all discovery mechanisms have security holes, you may want to
> look into
> https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05.

It seems to me that this draft has exactly the same problem as every
other "resolver discovery" proposal: it gives complete power to the
access network to indicate the resolver to use. If you use DoH/DoT, it
is because you don't trust the access network. Relying on it to
indicate a DoH/DoT resolver is pointless.

For instance, if your access provider has a lying resolver and you
want to escape it with DoH/DoT access to an external resolver, I don't
see how this draft helps you.

---

From: Neil Cook <[email-masked]>
Date: Wed, 27 Nov 2019 14:40:23 +0000

> On 27 Nov 2019, at 14:22, Konda, Tirumaleswar Reddy <[email-masked]> wrote:
> 
>> 

I’m not arguing that DHCP is secure, I’m arguing that discovery isn’t worthless., The client is free to use other mechanisms to decide whether to trust the DoH server returned as part of the discovery mechanism. For example if the resolver discovery returns the DoH server for that resolver as “myisp.net”, then the client can verify not only that the certificate matches myisp.net <http://myisp.net/>, but also whether it trusts “myisp.net <http://myisp.net/>” for DNS resolution. This is essentially the approach that Chrome is already taking with DoH, except that it currently lacks the discovery part.

Another use-case for discovery would be the case where I have manually entered a DNS server (e.g. 1.1.1.1). By default I can use DNS53 or DoT to that server, but not DoH. However with discovery I could ask (using either DNS53 or DoH) the 1.1.1.1 resolver if it supports DoH and if so on what URL.

Neil

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 14:42:50 +0000

> From: Stephane Bortzmeyer <[email-masked]>
> Sent: Wednesday, November 27, 2019 7:59 PM
> Cc: Stephane Bortzmeyer <[email-masked]>; Phillip Hallam-Baker
> <[email-masked]>; [email-masked]
> On Wed, Nov 27, 2019 at 09:07:15AM +0000,  Konda, Tirumaleswar Reddy
> <[email-masked]> wrote  a message of 72 lines
> which said:
> 
> > Not all discovery mechanisms have security holes, you may want to look
> > into
> It seems to me that this draft has exactly the same problem as every other
> "resolver discovery" proposal: it gives complete power to the access network
> to indicate the resolver to use. 

No, the client makes a decision whether to use the local resolver or not, please see https://tools.ietf.org/html/draft-reddy-dprive-dprive-privacy-policy-01#section-2 
I will update the draft in the next revision to make it more clear.

> If you use DoH/DoT, it is because you don't
> trust the access network. Relying on it to indicate a DoH/DoT resolver is
> pointless.

Agreed, the bootstrapping procedure is not implicitly triggered. You may want to look into https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-05#section-11.  It is similar to way VPN is enabled implicitly in all networks and the user 
has to explicitly disable VPN connection in specific network (e.g., Home network with security service to filter malware).

Cheers,
-Tiru

> 
> For instance, if your access provider has a lying resolver and you want to
> escape it with DoH/DoT access to an external resolver, I don't see how this
> draft helps you.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 27 Nov 2019 15:44:55 +0100

On Wed, Nov 27, 2019 at 10:04:57AM +0000,
 Neil Cook <[email-masked]> wrote 
 a message of 45 lines which said:

> I don’t see why they’re broken by design;

You explained it well:

> they add no security properties

> on top of the (insecure) DHCP mechanism used to contact the resolver
> in the first place

And the problem is not the (in)security of DHCP. The problem is that
if you don't trust the access network to provide you with a secure
resolver, why would you trust it to indicate one? If the default
resolver (DNS over UDP, obtained through DHCP) lies or records
personal data, why would the resolver found by "resolver discovery" be
better?

> how clients use that information is up to them. They may or may not
> decide to trust that resolver,

OK, if it is clearly specified, I understand. But it is far from
clear, for instance in draft-reddy-dprive-bootstrap-dns-server.

---

From: Neil Cook <[email-masked]>
Date: Wed, 27 Nov 2019 14:55:08 +0000

> On 27 Nov 2019, at 14:28, Stephane Bortzmeyer <[email-masked]> wrote:

> If you use DoH/DoT, it is because you don't trust the access network.

It says nothing about whether you trust the access network. You *may* be using DoH/DoT because you don’t trust the access network. However, you may trust the access network for example, but the resolver it gives you may be located somewhere else entirely and your queries may be transiting over an untrusted network.

> Relying on it to

You’re conflating the lack of trust in the access network with discovery. Yes, if you don’t trust the access network then you may not want to use a discovery protocol to indicate the best way to contact the resolver over DoT/DoH. 

However what if you have configured a resolver manually using an IP address, and want to opportunistically upgrade to DoT/DoH if the resolver supports it?

Neil

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 15:01:08 +0000

Please see inline

From: Neil Cook <[email-masked]>
Sent: Wednesday, November 27, 2019 8:10 PM
To: Konda, Tirumaleswar Reddy <[email-masked]>
Cc: Stephane Bortzmeyer <[email-masked]>; [email-masked]; Phillip Hallam-Baker <[email-masked]>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

On 27 Nov 2019, at 14:22, Konda, Tirumaleswar Reddy <[email-masked]<mailto:[email-masked]>> wrote:

I’m not arguing that DHCP is secure, I’m arguing that discovery isn’t worthless.,

[TR] I am only saying DHCP is not right discovery technique mechanism but I am not opposing discovery.

The client is free to use other mechanisms to decide whether to trust the DoH server returned as part of the discovery mechanism. For example if the resolver discovery returns the DoH server for that resolver as “myisp.net<http://myisp.net>”, then the client can verify not only that the certificate matches myisp.net<http://myisp.net>, but also whether it trusts “myisp.net<http://myisp.net>” for DNS resolution.

[TR] You may want to re-look into the attack I explained in the previous e-mail, client will use CloudFlare DoH server trusted by the browser (whereas the network is using Quad9/OpenDNS for malware filtering).

This is essentially the approach that Chrome is already taking with DoH, except that it currently lacks the discovery part.

[TR] The above discovery is more straightforward, client can query for the URI resource record type using https://tools.ietf.org/html/rfc7553

Cheers,
-Tiru

Neil

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Wed, 27 Nov 2019 15:25:00 +0000

> Sent: Wednesday, November 27, 2019 8:25 PM
> Cc: Konda, Tirumaleswar Reddy <[email-masked]>;
> [email-masked]; Phillip Hallam-Baker <[email-masked]>
> It says nothing about whether you trust the access network. You *may* be
> using DoH/DoT because you don’t trust the access network. However, you
> may trust the access network for example, but the resolver it gives you may
> be located somewhere else entirely and your queries may be transiting over
> an untrusted network.

Yes. In addition, Internal attacks have become a reality, please see https://tools.ietf.org/html/draft-arkko-arch-internet-threat-model-01#section-4.2.1. 
Clients should use DoT/DoH in all networks.

-Tiru

> You’re conflating the lack of trust in the access network with discovery. Yes, if
> you don’t trust the access network then you may not want to use a discovery
> protocol to indicate the best way to contact the resolver over DoT/DoH.
> 
> However what if you have configured a resolver manually using an IP address,
> and want to opportunistically upgrade to DoT/DoH if the resolver supports it?
> 
> Neil

---

From: "Winfield, Alister" <[email-masked]>
Date: Wed, 27 Nov 2019 15:53:10 +0000

I suspect that here is a problem made worse by assuming a single all-encompassing list of ‘trusted’ services. Personally I would hope eventually to have an administrator set policy on what DoH services to trust. This could be simple like only quad9 or more complex set allowing different providers depending upon the context. In your example the application would see CloudFlare and then refuse to use it.

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

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

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 27 Nov 2019 16:05:48 +0000

On 11/27/19, 9:29 AM, "dns-privacy on behalf of Stephane Bortzmeyer" <[email-masked] on behalf of [email-masked]> wrote:

>    For instance, if your access provider has a lying resolver

I just wanted to take a moment to note that choosing to use the term 'lying' when describing resolver behavior is unnecessarily negative and seems designed to be intentionally divisive. This does not IMO contribute to a productive discussion and exchange of views at the IETF.

As has been long demonstrated here and in DNSOP, not all DNS modification can be considered 'lying' - given that lying obviously implies it is a negative thing that is counter to user preferences. For example, an opt-in parental control service that modifies responses is not a negative use case from the perspective of that user/parent. Similarly, a DNS modification in an enterprise that blocks malware C2 FQDNs is also from the enterprise's perspective a good thing.

It seems a better approach is to simply use a neutral term and call this DNS modification. Whether that is good or bad will depend on the particular use case or situation or other factors.

Thanks
Jason

---

From: "Livingood, Jason" <[email-masked]>
Date: Wed, 27 Nov 2019 16:14:56 +0000

On 11/27/19, 9:55 AM, "dns-privacy on behalf of Neil Cook" <[email-masked] on behalf of [email-masked]> wrote:
>It says nothing about whether you trust the access network.

[JL] I agree with Neil. IMO the use of encrypted DNS is orthogonal to whether or not you trust your access network. For example, in the case of a user being concerned over the privacy of their queries to a public DNS that is a few hops off their ISP/enterprise/EDU/GOV network there are many networks that may or may not be trusted or even known by the end user. So suggesting that encryption of DNS is solely because of access network issues does not make sense - there are many reasons and many potential threats and risks where encryption may help that have nothing to do with that.

> You’re conflating the lack of trust in the access network with discovery. Yes, if you don’t trust the access network then you may not want to use a discovery protocol to indicate the best way to co…

[JL] Today we have nothing but manually crafted whitelists, etc. So anything automated will be better IMO. A discovery mechanism just provides info though - it does not mandate trust or a particular OS or app/client decision. So a browser in one example can take the info from DHCP or similar automated discovery mechanism and take it as a useful bit of data or choose to ignore it, based on app or user decision. It would seem our job is to specify potential discovery mechanisms - each of which will come with pros/cons/risks (and none being perfect) for various use cases - and let the client/app or user decide what to do with that.

---

From: Andrew Campling <[email-masked]>
Date: Wed, 27 Nov 2019 22:09:00 +0000

+1 to Jason's comment - suggesting all DNS modification is bad indicates a misunderstanding of some real-world use cases.

Andrew

-----Original Message-----
From: Livingood, Jason <[email-masked]>
Sent: 27 November 2019 16:06
To: Stephane Bortzmeyer <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

Thanks
Jason

---

From: "Konda, Tirumaleswar Reddy" <[email-masked]>
Date: Thu, 28 Nov 2019 11:05:11 +0000

In addition, with the extended error codes defined in https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08, client would know the reason for blocking access to a domain, solves the user experience problem and, DoT/DoH ensures the error response is not spoofed.

-Tiru

From: dns-privacy <[email-masked]> On Behalf Of Andrew Campling
Sent: Thursday, November 28, 2019 3:39 AM
To: Livingood, Jason <[email-masked]>; Stephane Bortzmeyer <[email-masked]>; [email-masked]
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

Andrew

-----Original Message-----
From: Livingood, Jason <[email-masked]<mailto:[email-masked]>>
Sent: 27 November 2019 16:06
To: Stephane Bortzmeyer <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [dns-privacy] Trying to understand DNS resolver 'discovery'

Thanks
Jason

---

From: Kenji Baheux <[email-masked]>
Date: Fri, 29 Nov 2019 09:40:47 +0900

On Thu, Nov 28, 2019 at 8:05 PM Konda, Tirumaleswar Reddy <
[email-masked]> wrote:

> In addition, with the extended error codes defined in
> https://tools.ietf.org/html/draft-ietf-dnsop-extended-error-08, client
> would know the reason for blocking access to a domain, solves the user
> experience problem and, DoT/DoH ensures the error response is not spoofed.
>

Spot on.

A big part of the problem is that the DNS modifications for legit use cases
or legal reasons are done in a non-transparent way, with potential
security/privacy side-effects (e.g. application left in the dark, forced
custom page), and without strong guarantees that this was indeed the
original intent. That said, I understand the need for ISP or service
operators to explain what happened to the user and how to act on it (e.g.
request whitelisting in a parental control situation).

So, I'd love to hear feedback from ISPs in particular, on the extended DNS
error draft in conjunction with DoH.
An alternative would be to use/repurpose HTTP status code such as 451
or 450 in DoH, and also define something for the explanation needs.

>
>
> -Tiru
>
>
>
> *From:* dns-privacy <[email-masked]> *On Behalf Of *Andrew
> Campling
> *Sent:* Thursday, November 28, 2019 3:39 AM
> *To:* Livingood, Jason <[email-masked]>; Stephane Bortzmeyer
> <[email-masked]>; [email-masked]
> *Subject:* Re: [dns-privacy] Trying to understand DNS resolver 'discovery'
>
>
>
> *CAUTION*: External email. Do not click links or open attachments unless
> you recognize the sender and know the content is safe.
>
>
> ------------------------------
>
> +1 to Jason's comment - suggesting all DNS modification is bad indicates a
> misunderstanding of some real-world use cases.
>
>
>
> *Andrew*
>
>
>
> I just wanted to take a moment to note that choosing to use the term
> 'lying' when describing resolver behavior is unnecessarily negative and
> seems designed to be intentionally divisive. This does not IMO contribute
> to a productive discussion and exchange of views at the IETF.
>
>
>
> As has been long demonstrated here and in DNSOP, not all DNS modification
> can be considered 'lying' - given that lying obviously implies it is a
> negative thing that is counter to user preferences. For example, an opt-in
> parental control service that modifies responses is not a negative use case
> from the perspective of that user/parent. Similarly, a DNS modification in
> an enterprise that blocks malware C2 FQDNs is also from the enterprise's
> perspective a good thing.
>
>
>
> It seems a better approach is to simply use a neutral term and call this
> DNS modification. Whether that is good or bad will depend on the particular
> use case or situation or other factors.
>
>
>
> Thanks
>
> Jason
>
>
>
>
>
>

-- 
Kenji BAHEUX
Product Manager - Chrome
Google Japan