Subject: [DNSOP] New draft for helping browsers use the DoH server associated with a resolver

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Aug 2018 00:01:33 +0000

Greetings again. Some of the people in the recent thread about "dynamic discovery of secure resolvers" have expressed an interest in something that was mentioned at the DRIU BoF in Montréal: they want their browser to use a DoH server that is related to the DNS resolver that their OS is already using. I don't think DHCP can help with that problem (I could be wrong), but I do think that resolver operators should be able to tell browsers the DoH resolvers that they would want their customers to be using.

Please see the draft below. If folks like it, I can continue to work on it. Or, if you like the use case but have a better technical solution, that would be great too. I wanted to bring it to this list before taking it to the DOH WG because it really is an operational issue, not all that related to the DoH protocol.

Thoughts?

--Paul Hoffman

A New Internet-Draft is available from the on-line Internet-Drafts directories. 

Title : Associating a DoH Server with a Resolver 
Author : Paul Hoffman 
Filename : draft-hoffman-resolver-associated-doh-00.txt 
Pages : 8 
Date : 2018-08-23 

Abstract: 
Some clients will want to know if there are one or more DoH servers 
associated with the DNS recursive resolver that the client is already 
using. This document describes a protocol for a resolver to tell a 
client what its associated DoH servers are. 

The IETF datatracker status page for this draft is: 
https://datatracker.ietf.org/doc/draft-hoffman-resolver-associated-doh/

There are also htmlized versions available at: 
https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-00
https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh-00

Please note that it may take a couple of minutes from the time of submission 
until the htmlized version and diff are available at tools.ietf.org. 

Internet-Drafts are also available by anonymous FTP at: 
ftp://ftp.ietf.org/internet-drafts/

---

From: "John Todd" <[email-masked]>
Date: Thu, 23 Aug 2018 18:29:31 -0700

Wouldn’t that be simpler to use SRV, and require no new RRTYPE? If a 
previously-granted resolver via DHCP was 192.168.1.1, then a lookup and 
result of:

  _doh._tcp.1.1.168.192.in-addr.arpa.  86400 IN SRV 10 60 443 
dns-doh.example.com.

  …would provide the client with a DOH resolver at 
“dhs-doh.example.com” after a subsequent and hopefully final non-DOH 
lookup on the name(s). Or multiple DOH resolvers could be returned, if 
one wished to use SRV expansion to its full extent.

  I know there are some leakage problems here in certain cases to 
upstream resolvers, and there is a serious fundamental problem with the 
first-query (bootstrap) trust chain in a practical sense, but the same 
issue exists with a new RR type and I suspect will be far longer to 
implement a new RR type than to use SRV which already exists. I see the 
risks as close to identical.

  “DOH” of course isn’t an official service name, but RFC2782 
allows for service names that are local, so maybe there is a task to get 
“doh” turned into an official service name but in the meantime it 
can work without official nomenclature. It’s entirely possible 
“doh” is already on track or listed as a service name and I’ve 
missed it, despite the fact that it is really just HTTPS, even though 
we’re overloading the service type, as seems to be the case for 
[everything]-over-HTTPS.  That seems thin as an objection.

  I’m probably overlooking an obvious reason that this isn’t a use 
case for SRV, but it’s been a long day in a different timezone than 
I’m used to. Slings and arrows welcome.

JT

On 23 Aug 2018, at 17:01, Paul Hoffman wrote:

> Greetings again. Some of the people in the recent thread about 
> "dynamic discovery of secure resolvers" have expressed an interest in 
> something that was mentioned at the DRIU BoF in Montréal: they want 
> their browser to use a DoH server that is related to the DNS resolver 
> that their OS is already using. I don't think DHCP can help with that 
> problem (I could be wrong), but I do think that resolver operators 
> should be able to tell browsers the DoH resolvers that they would want 
> their customers to be using.
>
> Please see the draft below. If folks like it, I can continue to work 
> on it. Or, if you like the use case but have a better technical 
> solution, that would be great too. I wanted to bring it to this list 
> before taking it to the DOH WG because it really is an operational 
> issue, not all that related to the DoH protocol.
>
> Thoughts?
>
> --Paul Hoffman
>
> _______________________________________________
> DNSOP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dnsop

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Aug 2018 02:04:16 +0000

On Aug 23, 2018, at 6:29 PM, John Todd <[email-masked]> wrote:
> 
> 
> Wouldn’t that be simpler to use SRV, and require no new RRTYPE? If a previously-granted resolver via DHCP was 192.168.1.1, then a lookup and result of:
> 
> _doh._tcp.1.1.168.192.in-addr.arpa.  86400 IN SRV 10 60 443 dns-doh.example.com.
> 
> …would provide the client with a DOH resolver at “dhs-doh.example.com” after a subsequent and hopefully final non-DOH lookup on the name(s). Or multiple DOH resolvers could be returned, if one wished to use SRV expansion to its full extent.

I don't think this works for two orthogonal reasons:

- The browser doesn't necessarily know that address of the recursive resolver, just how to send queries to the recursive resolver through the OS's stub resolver

- Recursive resolvers don't all have control of their reverse address mappings in in-addr.arpa.

Even if both of those are fixed, it will yield less secure results because in-addr.arpa is not signed in DNSSEC, so attackers in the middle will always be able to change the responses (as compared to only being able to some of the time with the RAD RRtype I proposed).

> I know there are some leakage problems here in certain cases to upstream resolvers, and there is a serious fundamental problem with the first-query (bootstrap) trust chain in a practical sense, but the same issue exists with a new RR type

Fully agree

> and I suspect will be far longer to implement a new RR type than to use SRV which already exists.

This doesn't seem to as daunting to me. On the client side, if a browser has a DoH client, it already has a full DNS stack, so adding in the requirement to be able to ask for RRtype TBD seems trivial. On the resolver side, it needs to have generic capture code to look for ./IN/RAD, and resolvers already have much more complicated code in them.

> I see the risks as close to identical.
> 
> “DOH” of course isn’t an official service name, but RFC2782 allows for service names that are local, so maybe there is a task to get “doh” turned into an official service name but in the meantime it can work without official nomenclature. It’s entirely possible “doh” is already on track or listed as a service name and I’ve missed it, despite the fact that it is really just HTTPS, even though we’re overloading the service type, as seems to be the case for [everything]-over-HTTPS.  That seems thin as an objection.
> 
> I’m probably overlooking an obvious reason that this isn’t a use case for SRV, but it’s been a long day in a different timezone than I’m used to. Slings and arrows welcome.

Hopefully the above is neither slings nor arrows!

--Paul Hoffman

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 24 Aug 2018 15:43:51 +0200

> Thoughts?

Well, if the OS resolver is validating, it will SERVFAIL with such a
query.  Furthermore, if it uses aggressive caching, it may even give a
negative reply without asking upstream that would answer positively. 
That is, unless the RFC instructs forwarding resolvers to do otherwise,
but that would seem a nasty special case for little benefit.

I assume the non-validation is a conscious tradeoff, as such resolvers
seem not a common OS default, and they're more likely to support DoT or
DoH anyway, hopefully reducing the need for browsers to roll their own.

I'm not sure I understand the motivation for the stated use case, but
apparently others perceive it as useful...

--Vladimir

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Aug 2018 14:25:30 +0000

On Aug 24, 2018, at 6:43 AM, Vladimír Čunát <[email-masked]> wrote:
> query.  

The protocol requires special handling of those specific queries, so a resolver that understands the protocol will give the desired answer. A resolver that doesn't understand the answer will give NXDOMAIN even if it is validating because that RRtype is not in the root zone.

> Furthermore, if it uses aggressive caching, it may even give a

...which is fine for resolvers that do not know the protocol.

> but that would seem a nasty special case for little benefit.

Forwarding resolvers do not need special casing, I believe. If the forwarding resolver understands the protocol, it will reply. If it doesn't understand the protocol, it will forward and give back whatever the upstream resolver tells it. 

> DoH anyway, hopefully reducing the need for browsers to roll their own.

I admit I had not considered validating stub resolvers. Now that you bring it up, a validating stub resolver will get an answer that cannot be validated, and thus will mark it Bogus. This feels like a limitation, but one that can't really be worked around unless we use a RFC 6761 TLD that is guaranteed to be unsigned.

> apparently others perceive it as useful...

Restating the motivation: a browser that wants to use DoH might also want to let the user say "I trust the DoH server that my configured resolver is associated with". That eliminates the need to have DHCP know which DoH servers are associated with the Do53 servers that it is announcing, and it also eliminates the need for the OS to know about those DHCP updates.

Hopefully this helps. But thank you for bringing up the validating stub issue.

--Paul Hoffman

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 24 Aug 2018 16:44:36 +0200

> Forwarding resolvers do not need special casing, I believe. If the forwarding resolver understands the protocol, it will reply. If it doesn't understand the protocol, it will forward and give back…

Oh, I assumed (perhaps wrongly) that if the OS resolver forwards to some
other resolver that can do DoH, you want the browser to use *that* DoH
instead of the OS resolver, at least in the usual case when there's not
a good channel to the OS resolver itself.  If the OS resolver validates,
I don't see much difference between being a "stub" or forwarding.

Anyway, all the notes I've written are about an edge case that seem a
small fraction in practice - dumb stub without validation and without
secure transport is still the default almost everywhere, I'm afraid.

I believe I understood what you mean by the "motivation" - confirmed by
you restating it.  I still can't really understand why that group of
cases is considered useful, but presumably browser/DoH people know
better what most of their users want.

--Vladimir

---

From: Philip Homburg <[email-masked]>
Date: Fri, 24 Aug 2018 16:45:12 +0200

> The protocol requires special handling of those specific queries,
> so a resolver that understands the protocol will give the desired
> answer. A resolver that doesn't understand the answer will give
> NXDOMAIN even if it is validating because that RRtype is not in
> the root zone.

It seems to go wrong when you have one validating resolver that forwards to a
resolver that supports this mechanism.

It don't really see the point of what you propose. For resolvers obtained by
DHCP it makes more sense to include the URL in the DHCP reply than to have
yet another DNSSEC-violating discovery hack.

For manually configured resolvers, it is likely more convenient for the user
to just enter the URL and let the system figure out the addresses of the
resolvers.

Figuring out what SNI to use using insecure DNS sort of negates any advantage
TLS authentication offers.

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 24 Aug 2018 14:56:12 +0000

> resolver that supports this mechanism.

Agree. This might mean that using an unsigned 6761 special use domain name would be better.

> yet another DNSSEC-violating discovery hack.

Two reasons here (although they might not be convincing):

- This proposal works for browsers even if the OS doesn't understand a new DHCP extension for DoH server URI templates

- It relives the DHCP server admin from needing to know which DoH servers are associated with a particular Do53 server.

As I hope I made clear in the proposal, it will work even if there is a new DHCP extension for the OS. It just doesn't rely on it.

> to just enter the URL and let the system figure out the addresses of the

Again, it is not clear how that information would get to the browsers. They have a hard enough time getting good answers to "what is the address being used for the resolver".

> TLS authentication offers.

I don't understand this at all. The SNI is the host in the URI template.

--Paul Hoffman

---

From: Vladimír Čunát <[email-masked]>
Date: Fri, 24 Aug 2018 17:26:09 +0200

> I don't understand this at all. The SNI is the host in the URI template.

There remains the general problem with bootstrapping a "secure" channel
without using another secure anchor.  DHCP has the same problem - it's
not validable (reportedly, I don't know the protocol well).

You get a name (for SNI) and thus you can verify that you connect to
that name (https/tls), but you can't distinguish whether you got a
spoofed name in the first place, and I can't see a possible workaround
for that.  Both DHCP and this draft are essentially like not validating
identity of the other side but otherwise using a "secure" transport. 
Well, I think many people consider such opportunistic security schemes
to be noticeably better than cleartext.

Still, personally I'd probably prefer to choose someone from a list of
providers, as we might have quite a lot soon, and "I" might trust some
of the names already, and the handshake will then verify that the name
matches.  I assume this draft is meant as yet another fallback when such
user selection isn't suitable.  (Well, I'd most prefer to run a per-SOHO
or per-device validating resolver, in future maybe with TLS-forwarding
somewhere else, but that doesn't belong to this thread, and it isn't
suitable for most people anyway.)

--Vladimir

---

From: Shumon Huque <[email-masked]>
Date: Fri, 24 Aug 2018 12:36:07 -0400

On Fri, Aug 24, 2018 at 10:26 AM Paul Hoffman <[email-masked]>
wrote:

> The protocol requires special handling of those specific queries, so a
> resolver that understands the protocol will give the desired answer. A
> resolver that doesn't understand the answer will give NXDOMAIN even if it
> is validating because that RRtype is not in the root zone.
>

(Haven't read the draft yet, but a quick comment on this point ..)

Surely you mean NODATA (NOERROR + empty ANSWER section), since the root
domain name exists. If validating, it would additionally provide the signed
NSEC/NSEC3 record at the root disproving the existence of the RRtype.

Shumon

---

From: Vittorio Bertola <[email-masked]>
Date: Sat, 25 Aug 2018 10:12:27 +0200 (CEST)

> Il 24 agosto 2018 alle 17.26 Vladimír Čunát <[email-masked]> ha scritto: 
> 
> 
> Still, personally I'd probably prefer to choose someone from a list of providers, as we might have quite a lot soon, and "I" might trust some of the names already, and the handshake will then verify that the name matches.

While having users in charge might in the end be the best thing to balance all the conflicting interests and threat mitigation needs, I am not sure that putting the user in front of a list of all the existing DoH resolution providers (thousands? hundreds of thousands?) is a great idea. 

In terms of user experience, to allow users to make an informed choice, the list would need to provide users with information on the policy of each server (see the current draft in DPRIVE) and it would end up being pretty hard to lay out and use in a meaningful way. Also, if you can't even find a way to transmit securely to the user device the information on the single DoH resolver that serves the local network, how can you maintain and transmit securely an updated list of all the existing DoH providers?
 
On the other hand, you could imagine that the application, or the OS, could create its own shortlist of "approved" DoH resolvers and transmit it securely from its own servers, or include it in the application's installation procedure. But this would open up significant policy/legal issues in terms of antitrust and fair competition among DoH providers.
 
I'm not saying that there's no way to do it properly, but it is not as simple as it looks. 

In the end, the policy of having your names resolved by default by a local server on your access network, while leaving you free to configure a different resolver that you find out-of-band if you want to, emerged over 30 years because it makes a lot of sense. I still have to hear a compelling technical or policy reason for the attempt to change this default and turn DNS resolution into yet another over-the-top service subject to global competition and market consolidation, other than "there are some big companies that would like to resolve the names for the whole world because they can gain from the data they would gather".
 
Regards, 
-- 

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

---

From: Paul Vixie <[email-masked]>
Date: Sat, 25 Aug 2018 17:39:04 +0000

everyone, please listen.

On Saturday, August 25, 2018 8:12:27 AM UTC Vittorio Bertola wrote:
> ...
> In the end, the policy of having your names resolved by default by a local
> server on your access network, while leaving you free to configure a
> different resolver that you find out-of-band if you want to, emerged over
> 30 years because it makes a lot of sense. I still have to hear a compelling
> technical or policy reason for the attempt to change this default and turn
> DNS resolution into yet another over-the-top service subject to global
> competition and market consolidation, other than "there are some big
> companies that would like to resolve the names for the whole world because
> they can gain from the data they would gather". 

+1.

-- 
Vixie

---

From: Paul Hoffman <[email-masked]>
Date: Sat, 25 Aug 2018 22:22:41 +0000

Greetings again. Based on the technical input I received, I ripped out the first-guess mechanism and replaced it with one that will work with validating stub resolvers but still work with the same use cases.

It's clear some people here don't have the use cases listed in the draft; that's fine, lots of protocols don't apply to everyone. I do still believe that the folks who spoke up saying that they want their browsers to use DoH servers that are matched with the DNS-over-53 resolvers they chose, and this would allow that.

--Paul Hoffman

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-hoffman-resolver-associated-doh-01
https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-hoffman-resolver-associated-doh-01

---

From: "John Dickinson" <[email-masked]>
Date: Fri, 31 Aug 2018 15:36:29 +0100

Hi Paul,

Just trying to read this draft in detail and I find section 3 a bit 
confusing. You use terms such as client and resolver but at times it is 
not clear if you are referring to the OS stub, a third party stub, 
caching resolver, application or browser. Maybe using terms from your 
terminology draft would help.

Thanks
John

> ftp://ftp.ietf.org/internet-drafts/

John Dickinson

http://sinodun.com

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