Subject: [Doh] Associating a DoH server with a resolver

From: Paul Hoffman <[email-masked]>
Date: Tue, 23 Oct 2018 20:15:39 +0000

Post-RFC-publication greetings. One of the topics that has been active in the DNS community since the standardization of DoH is how a browser or web application could use the resolver that the operating system on which it is running as a DoH server, or at least to use a DoH server associated with that resolver. I have taken a few stabs at designing a protocol to make it possible to fulfill that need; the result is the draft below.

The draft is still in a very early stage. In fact, I've changed the underlying mechanism three times already because I forgot what browsers and operating systems could not do. I *think* the current draft is possible, but would not be surprised if someone pointed out that even this attempt is wrong. Regardless, the desire for such functionality seems strong.

Also note the Security Considerations section of the draft. In short: all this gives you is opportunistic encryption because (I believe) we can't get any better now. I would be happy to be wrong about that, of course.

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-04.txt
	Pages           : 8
	Date            : 2018-10-23

Abstract:
   Browsers and web applications may want to know if there are one or
   more DoH servers associated with the DNS recursive resolver that the
   operating system is already using.  This would allow them to get DNS
   responses from a resolver that the user (or, more likely, the user's
   network administrator) has already chosen.  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-04
https://datatracker.ietf.org/doc/html/draft-hoffman-resolver-associated-doh-04

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

---

From: "Hewitt, Rory" <[email-masked]>
Date: Tue, 23 Oct 2018 20:27:43 +0000

Very nice - this was indeed the topic of MUCH discussion!

I'm inclined to think that it might be better to be DNS-variant-agnostic -
rather than this:

	/.well-known/doh-servers-associated/

use this:

	/.well-known/dns-servers-associated/

or even just

	/.well-known/dns-servers/

where the URI Template response would indicate the type of DNS server (DoH,
DoT, Do53 etc.). It also allows for expansion if/when further DNS servers
are defined...

Rory

-----Original Message-----
From: Paul Hoffman <[email-masked]> 
Sent: Tuesday, October 23, 2018 1:16 PM
To: DoH WG <[email-masked]>
Subject: [Doh] Associating a DoH server with a resolver

Post-RFC-publication greetings. One of the topics that has been active in
the DNS community since the standardization of DoH is how a browser or web
application could use the resolver that the operating system on which it is
running as a DoH server, or at least to use a DoH server associated with
that resolver. I have taken a few stabs at designing a protocol to make it
possible to fulfill that need; the result is the draft below.

The draft is still in a very early stage. In fact, I've changed the
underlying mechanism three times already because I forgot what browsers and
operating systems could not do. I *think* the current draft is possible, but
would not be surprised if someone pointed out that even this attempt is
wrong. Regardless, the desire for such functionality seems strong.

Also note the Security Considerations section of the draft. In short: all
this gives you is opportunistic encryption because (I believe) we can't get
any better now. I would be happy to be wrong about that, of course.

Thoughts?

--Paul Hoffman

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

Abstract:

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

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 23 Oct 2018 17:05:17 -0400

Hi Paul, thanks for the continuing work on this topic.

Two related questions:
1. Does the resolver have to return its own IP in the RR for
resolver-addresses.arpa, or can it return some other IP addresses?
2. If a client has some OS-specific way to enumerate the DNS server IPs for
the default network interface, is it still required to perform "Step 1"?
(Most OSes do have some enumeration mechanism like this.)

Other minor comments:
On Section 4, User Interface: I don't see the need for a user interface
here.  In my view, opportunistic security generally shouldn't require user
action and shouldn't produce a user-visible change.

I think interaction with DoT is worth discussing here, even though it's
probably trivial.  If I can probe for DoT and (with this draft) DoH, which
one do I probe first, and which should I prefer if both succeed?

--Ben

On Tue, Oct 23, 2018 at 4:15 PM Paul Hoffman <[email-masked]> wrote:

> operating systems could not do. I *think* the current draft is possible,
> but would not be surprised if someone pointed out that even this attempt is
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 12:08:31 +1100

Why do the IP-based spelunking?  It requires that the resolver (which
might not be a DoH server) do HTTP as well.  Can't you define a record
that could be placed at the resolver-addresses.arpa name?  I hesitate
to say TXT, but I can't think of a good reason not to use that in this
case.  Multiple such records could identify different DNS-over-foo
variants.

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 12:10:31 +1100

> case.  Multiple such records could identify different DNS-over-foo

Oh, I forgot.  IP-based certificates complicate things considerably,
and will make this impossible to deploy in many cases (think of the
many resolvers with 1918 addresses, for example).

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 01:12:09 +0000

> case.  Multiple such records could identify different DNS-over-foo

Given the offline comments I'm getting similar to this one, I did not emphasize this enough in the draft.

There is no way for an application like a browser to send a query through the OS for anything other than address records. That is, gethostbyname() and its equivalents only pass back address records. Even if an application had its own DNS stack to make queries for other RRtypes, it doesn't have any way to know where to send them to.

If I'm wrong about the above, that's great, because we could certainly simplify the way that Martin suggests above or that I had in earlier versions of the draft.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 01:14:29 +0000

> many resolvers with 1918 addresses, for example).

They don't make it "impossible" by a long shot. Plenty of resolvers, even corporate resolvers, have public addresses.

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Wed, 24 Oct 2018 12:22:13 +1100

> There is no way for an application like a browser to send a query through the OS for anything other than address records. That is, gethostbyname() and its equivalents only pass back address records…

Well, resolver-addresses.arpa./IN/A(AAA) might still be useful for
that then.  That's not ideal, but I believe that there are ways to
make queries for other record types that are more available now than
perhaps there were in the past (see
https://docs.microsoft.com/en-us/windows/desktop/api/windns/nf-windns-dnsquery_a
for example).

>> IP-based certificates [...] impossible to deploy in many cases (think of the many resolvers with 1918 addresses, for example).
>

True, it is probably still possible, but it's not like you can just
use ACME to get the certificate.  That's "possible" in theory, but I'm
looking for practicable.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 23 Oct 2018 20:18:32 -0700

Several points here:

1. As a matter of aesthetics, I agree with Martin that domain names would
be better.
2. Martin sent a link to a method for resolving TXT records on Windows.
MacOS has its own API:
https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc
.
So, this doesn't seem prohibitive to me.
3. It seems like in the use case for which this draft is specified, the
whole thing is pretty opportunistic, so IP address certs wouldn't be
required.
4. There are other uses cases for which it might be nice to have real
domain names, in which case the IP address cert thing is a pain.

For these reasons, I think a domain name in TXT or the like would be better.

-Ekr

On Tue, Oct 23, 2018 at 6:22 PM Martin Thomson <[email-masked]>
wrote:

> > There is no way for an application like a browser to send a query
> through the OS for anything other than address records. That is,
> gethostbyname() and its equivalents only pass back address records. Even if
> an application had its own DNS stack to make queries for other RRtypes, it
> doesn't have any way to know where to send them to.
>
> >> IP-based certificates [...] impossible to deploy in many cases (think
> of the many resolvers with 1918 addresses, for example).
> >
> > They don't make it "impossible" by a long shot. Plenty of resolvers,
> even corporate resolvers, have public addresses.
>

---

From: Adam Roach <[email-masked]>
Date: Tue, 23 Oct 2018 22:39:45 -0500

On 10/23/18 10:18 PM, Eric Rescorla wrote:
> Several points here:
>
> 1. As a matter of aesthetics, I agree with Martin that domain names 
> would be better.
> 2. Martin sent a link to a method for resolving TXT records on 
> Windows. MacOS has its own API: 
> https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc.
> 3. It seems like in the use case for which this draft is specified, 
> the whole thing is pretty opportunistic, so IP address certs wouldn't 
> be required.

If we are going for non-A/AAAA record types, then I would suggest that 
we use the record to directly indicate the URI instead of having to 
synthesize one using a .well-known path. I would also point out that we 
already have a resource record type for converting desired services into 
URIs (RFC 7553).

So, e.g., interested clients would query for a URI record of type 
_doh._tcp.resolvers.arpa, and get back a full HTTPS URL as a response.

/a

---

From: Tony Finch <[email-masked]>
Date: Wed, 24 Oct 2018 12:24:28 +0100

> even corporate resolvers, have public addresses.

Both of our CAs will not give us iPAddress certificates.

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
Forties, Cromarty: West 5 to 7, occasionally gale 8 until later. Rough or very
rough. Occasional rain. Good occasionally poor.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 24 Oct 2018 12:09:38 -0400

On Tue, Oct 23, 2018 at 9:12 PM Paul Hoffman <[email-masked]> wrote:

>
> There is no way for an application like a browser to send a query through
> the OS for anything other than address records. That is, gethostbyname()
> and its equivalents only pass back address records

good news - that's not true. The concern is that other APIs often are DNS
only (and therefore break compatibility with other naming systems like
netbios, whatever).. however in the case that you're specifically looking
for DNS resolvers, that doesn't seem like a problem.

However I disagree with the premise of the work - browsers I have spoken
with do not seek to find a DoH version of a resolver that was discovered
from a broadcast address over a network that wasn't authenticated in the
first place and has an unknown trust relationship with the user in the
second case.

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 16:11:10 +0000

> https://docs.microsoft.com/en-us/windows/desktop/api/windns/nf-windns-dnsquery_a

I certainly don't want to preclude one-step ways of getting the associated URI templates in a single step, but I also don't want to only have the ability to get associated DoH servers be limited to browsers (because web applications can't call OS APIs), nor limited to browsers that are running on OSes that support sending TXT (or TXT-like) queries. 

> use ACME to get the certificate.  That's "possible" in theory, but I'm

You should be able to use ACME in the future to get an IP-based certificate. draft-ietf-acme-ip has been submitted to the IESG for publication.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 16:11:25 +0000

On Oct 23, 2018, at 8:18 PM, Eric Rescorla <[email-masked]> wrote:
> Several points here:
> 
> 1. As a matter of aesthetics, I agree with Martin that domain names would be better.

If we can get non-address records back, I would prefer to go all the way to "here are the URI templates of the DoH servers". No need to cause another round-trip.

> 2. Martin sent a link to a method for resolving TXT records on Windows. MacOS has its own API: https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc [developer.apple.com] <https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_documentation_dnssd_1804747-2Ddnsservicequeryrecord-3Flanguage-3Dobjc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=yvHk3BrvY-tKWGRmaFbQS1aHXNfQjC40fPfI5u1VsFs&m=iJ8qV6wySJ414-hN_AOIVx2XwwybAWbVxH5x8UIf4kQ&s=5WHmwl5icl3kObdG8_5f2rpWhKXSf4wIs0YR6IefeDA&e=>.

I thought this only worked for DNSSD, not DNS. Does it work for both? Or is there a similar-flavored Mac call for DNS?

> 3. It seems like in the use case for which this draft is specified, the whole thing is pretty opportunistic, so IP address certs wouldn't be required.

Agree. In the future, when an application can know that the OS's connection to the DNS resolver is authenticated, then IP address certs could be used for fully-authenticated communication. That doesn't seem likely any time soon, however, given the results of the discussions at the DRIU BoF at the last IETF meeting.

> 4. There are other uses cases for which it might be nice to have real domain names, in which case the IP address cert thing is a pain.
> 

Do you see a use case for domain names other than "here's a way to get to a well-known URI on the resolver"? If so, we could add that as well as "here are the URI templates for the associated DoH server.

--Paul Hoffman

---

From: Adam Roach <[email-masked]>
Date: Wed, 24 Oct 2018 11:17:50 -0500

> You should be able to use ACME in the future to get an IP-based certificate. draft-ietf-acme-ip has been submitted to the IESG for publication.

And CAB forum rules have allowed issuance of such certs for quite a 
while now. The issue isn't technology or permission -- it's CA policies. 
I think you'd need to find CAs willing to issue such certs before you 
feel comfortable predicating a technology on them.

/a

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 16:19:14 +0000

On Oct 23, 2018, at 8:39 PM, Adam Roach <[email-masked]> wrote:
> If we are going for non-A/AAAA record types, then I would suggest that we use the record to directly indicate the URI instead of having to synthesize one using a .well-known path. I would also point out that we already have a resource record type for converting desired services into URIs (RFC 7553).
> 
> So, e.g., interested clients would query for a URI record of type _doh._tcp.resolvers.arpa, and get back a full HTTPS URL as a response.

Using the URI RRtype is a possibility as long as we are sure that all the APIs that allow sending names with underscores (that is, names that are not hostnames). If not, then TXT or a new purpose-based RRtype that is like TXT would be better.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 16:21:55 +0000

On Oct 24, 2018, at 9:09 AM, Patrick McManus <[email-masked]> wrote:
> However I disagree with the premise of the work - browsers I have spoken with do not seek to find a DoH version of a resolver that was discovered from a broadcast address over a network that wasn't authenticated in the first place and has an unknown trust relationship with the user in the second case.

I would want to hear that directly from the browser vendors before abandoning this work, particularly because we are hearing a lot of interest from organizations who want it. Also, even if the browser vendors didn't want it, web application providers might want it.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 16:24:11 +0000

On Oct 24, 2018, at 9:17 AM, Adam Roach <[email-masked]> wrote:
> And CAB forum rules have allowed issuance of such certs for quite a while now. The issue isn't technology or permission -- it's CA policies. I think you'd need to find CAs willing to issue such certs before you feel comfortable predicating a technology on them.

At the last IETF meeting, I was told by one large CA that they have happily/profitably been issuing IP-address certs for years. OTOH, they did indicate that they didn't think many of their competitors were doing so.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 24 Oct 2018 11:16:19 -0700

On Wed, Oct 24, 2018 at 9:11 AM Paul Hoffman <[email-masked]> wrote:

> If we can get non-address records back, I would prefer to go all the way
> to "here are the URI templates of the DoH servers". No need to cause
> another round-trip.
>
> MacOS has its own API: https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc
> [developer.apple.com]
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__developer.apple.com_documentation_dnssd_1804747-2Ddnsservicequeryrecord-3Flanguage-3Dobjc&d=DwMFaQ&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=yvHk3BrvY-tKWGRmaFbQS1aHXNfQjC40fPfI5u1VsFs&m=iJ8qV6wySJ414-hN_AOIVx2XwwybAWbVxH5x8UIf4kQ&s=5WHmwl5icl3kObdG8_5f2rpWhKXSf4wIs0YR6IefeDA&e=>
> .
> I thought this only worked for DNSSD, not DNS. Does it work for both? Or
> is there a similar-flavored Mac call for DNS?
>

I am reliably informed it works for ordinary DNS.

Do you see a use case for domain names other than "here's a way to get to a
> well-known URI on the resolver"? If so, we could add that as well as "here
> are the URI templates for the associated DoH server.
>

I think templates would be fine.

-Ekr

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 24 Oct 2018 18:25:02 +0000

On Oct 24, 2018, at 11:16 AM, Eric Rescorla <[email-masked]> wrote:
> 
> On Wed, Oct 24, 2018 at 9:11 AM Paul Hoffman <[email-masked] <mailto:[email-masked]>> wrote:
> On Oct 23, 2018, at 8:18 PM, Eric Rescorla <[email-masked] <mailto:[email-masked]>> wrote:
>> Several points here:
>> 

Yay!

> I think templates would be fine.

Sounds good. In the next draft I'll add back in the way of getting the templates directly in one DNS call for browsers that can do that, and will say that it SHOULD be used first.

I'll let the various ADs decide where this document should end up, if anywhere.

--Paul Hoffman

---

From: Christopher Wood <[email-masked]>
Date: Wed, 24 Oct 2018 20:29:18 -0700

On Wed, Oct 24, 2018 at 11:25 AM Paul Hoffman <[email-masked]> wrote:
>> 2. Martin sent a link to a method for resolving TXT records on Windows. MacOS has its own API: https://developer.apple.com/documentation/dnssd/1804747-dnsservicequeryrecord?language=objc [developer.apple.com].

Chiming in to confirm this is accurate. :-)

Best,
Chris

---

From: Jim Reid <[email-masked]>
Date: Thu, 25 Oct 2018 12:38:17 +0100

> Both of our CAs will not give us iPAddress certificates.

I’m fairly sure there’s an RIR based not a million miles away from Amsterdam who would be delighted to issue with certificates for your IP addresses.

---

From: Tony Finch <[email-masked]>
Date: Thu, 25 Oct 2018 12:43:11 +0100

Jim Reid <[email-masked]> wrote:
> I’m fairly sure there’s an RIR based not a million miles away from
> Amsterdam who would be delighted to issue with certificates for your IP
> addresses.

I don't think RPKI will be much use for web PKI purposes :-)

Tony.
-- 
f.anthony.n.finch  <[email-masked]>  http://dotat.at/
strengthen the democratic process and ensure that
there is a just and representative system of government

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 25 Oct 2018 14:57:09 +0000

Sorry for the belated reply to this. Gotta love corporate mail systems...

On Oct 23, 2018, at 2:05 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 1. Does the resolver have to return its own IP in the RR for resolver-addresses.arpa, or can it return some other IP addresses?

The current wording is that the resolver returns its own IP address, which makes the resolver operator responsible for running the service that will respond to the well-known URI. There is no expectation that the URI templates returned from the well-known URI will all point to that same resolver; it would be find for the resolver operator to point to trusted third-party services.

> 2. If a client has some OS-specific way to enumerate the DNS server IPs for the default network interface, is it still required to perform "Step 1"?  (Most OSes do have some enumeration mechanism like this.)

Good point; I'll add this to the next draft and say "no". I'll also say "if the application can enumerate the OS's preferred DoH servers, there is no need to use the protocol here at all".

> Other minor comments:
> On Section 4, User Interface: I don't see the need for a user interface here.  In my view, opportunistic security generally shouldn't require user action and shouldn't produce a user-visible change.

Browser vendors might prefer that, privacy-concerned users might want a UI. I guess I'm targeting the latter.

> I think interaction with DoT is worth discussing here, even though it's probably trivial.  If I can probe for DoT and (with this draft) DoH, which one do I probe first, and which should I prefer if both succeed?

Yes, I'll add a stub for discussion of this.

--Paul Hoffman

---

From: Adam Roach <[email-masked]>
Date: Thu, 25 Oct 2018 10:35:05 -0500

> Browser vendors might prefer that, privacy-concerned users might want a UI. I guess I'm targeting the latter.

You cast this as a matter of user agency, while the analysis that's been 
done in this space has concluded that these kinds of indicators for 
opportunistic security are quite hostile to user interests.

It's hard to convey the subtlety of "you might be talking to the wrong 
thing, and there might be undetectable on-path attackers reading and 
modifying your data, but at least passive attackers can't see what's 
going on." And users who overestimate the level of protection implied by 
security indicia run a high risk of behaving in a way that does not suit 
their interests.

/a

---

From: Eliot Lear <[email-masked]>
Date: Thu, 25 Oct 2018 19:58:04 +0200

On 24.10.18 18:09, Patrick McManus wrote:
>
> However I disagree with the premise of the work - browsers I have
> spoken with do not seek to find a DoH version of a resolver that was
> discovered from a broadcast address over a network that wasn't
> authenticated in the first place and has an unknown trust relationship
> with the user in the second case.

If you're referring to DHCP, I think it's worth stepping through the
entire trust model and comparing before we get to sweeping generalizations.

Eliot