Subject: [Doh] Use cases and URLs

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2018 03:49:26 +0000

Greetings again. In the discussions in the last month since draft-ietf-doh-dns-over-https-03 came out, particularly at the DNS Privacy Workshop at NDSS, it has become clear that there are a lot of use cases that are related to the two given in Section 3 of the draft, but are not called out explicitly. They fall under the sentence "They might use the DOH server for all queries, or only for a subset of them."

Some that I have heard are (approximately):

- Use the preferred DNS API server for all DNS lookups in the browser whenever the browser is running (start the TLS session with the DNS API when the browser starts).

- If a tab/window for the origin of a configured DNS API server is open, use the configured API server for all DNS lookups.

- If a tab/window for the origin of a configured DNS API server is open, use the configured API server for DNS lookups that are in that origin only.

- If a tab/window for the origin of a configured DNS API server is open, and the configured API server pushes DNS information, accept it.

(Note that you might like or dislike some of these; that's fine.)

In addition, there has been the assumption by many people that they could add new DNS API servers to the list of configured servers in the browser based on various out-of-band information (articles, word-of-mouth, ...). That is, people want the additional DNS privacy through a somewhat-trusted web site rather than no privacy from the who-knows-where they are getting now. (Don't forget that the vast, vast majority of users are doing DNS lookups using resolvers they have no idea about.)

The ability to add new DNS APIs servers leads to the question of the URL being used for a particular DNS API server. In early drafts, we used "https://<origin>/.well-known/dns-query?..." as the standard URL, but it was pointed out that such a standard is prohibited by RFC 5785. The current draft says that there is no standard, and every origin will have its own URL for the API. This makes it much harder for a user to add new configured DNS API servers and thus reduces the chance that some of their DNS queries will be private, based on which of the use cases get implemented.

A protocol point between "here is the fixed URL" and "every origin has its own URL" is "discover the policy for an origin to serve as a DNS API server". That is, use the RFC 5785 ".well-known" scheme as a way to find out what the origin's policy is. That way, a user can configure new servers in their browser only knowing the origin name (which is all they really understand anyway...).

A first guess of a proposal would be that "https://<origin>/.well-known/dns-query/" returns a JSON object that looks like:
   { "has-DNS-API": true, "DNS-API-URLs":
      [ "https://<origin>/admin-dns/?", "https://<origin>/backup-dns/?" ] }

This uses the .well-known for what it is supposed to be used for, and gives each origin a chance to pick their own URL scheme. Getting no response or "{ "has-DNS-API": false }" both tell the user that origin's policy as well, of course.

Thoughts?

--Paul Hoffman

---

From: Adam Roach <[email-masked]>
Date: Tue, 6 Mar 2018 22:04:05 -0600

On 3/6/18 9:49 PM, Paul Hoffman wrote:
> The current draft says that there is no standard, and every origin will have its own URL for the API. This makes it much harder for a user to add new configured DNS API servers

Can you elaborate on this a bit? I fully expect that the typical 
user-self-provisioning case will involve copy/pasting server 
information, in which case the difference between a server and a URL is 
pretty minimal. Do you expect users to type server names in rather than 
copying them?

/a

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2018 05:28:19 +0000

On Mar 6, 2018, at 20:04, Adam Roach <[email-masked]> wrote:
> Can you elaborate on this a bit? I fully expect that the typical user-self-provisioning case will involve copy/pasting server information, in which case the difference between a server and a URL is pretty minimal. Do you expect users to type server names in rather than copying them?

Yes, exactly. If someone tells you that your bank runs this secure DNS server, that’s verbal, not copy and paste.

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 7 Mar 2018 16:41:17 +1100

Is making it super-easy for non-technical end users to configure a new DNS server a feature or a bug?

> On 7 Mar 2018, at 4:28 pm, Paul Hoffman <[email-masked]> wrote:
> 
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh

--
Mark Nottingham   https://www.mnot.net/

---

From: Patrick McManus <[email-masked]>
Date: Wed, 7 Mar 2018 16:11:01 -0500

On Wed, Mar 7, 2018 at 12:28 AM, Paul Hoffman <[email-masked]>
wrote:

> user-self-provisioning case will involve copy/pasting server information,
> in which case the difference between a server and a URL is pretty minimal.
> Do you expect users to type server names in rather than copying them?
>
> Yes, exactly. If someone tells you that your bank runs this secure DNS
> server, that’s verbal, not copy and paste.
>
>
I don't agree with this.

Its logically an argument for not even using hostnames. The minimal
information in your example is your bank - so just assume www.BANK.com.
That's certainly easier to convey though it has some obvious shortcomings.

But even if you argue hostname is the goldilocks of granularity, the DNS
resolver market has already shown that its not rich enough. note that
quad-9 offers both 9.9.9.9 and 9.9.9.10 and that 10 is not simply a
secondary for .9 but its a different service with different policies and
different results.. but because the configuration scheme of traditional DNS
is so coarse they needed to burn IPv4 addresses just to convey
configuration information. Your suggestion uplevels that from 1 address to
1 hostname but the fundamental problem remains.

Lastly, we want this work to be consistent with the BCP56bis work which
explicitly talks about Initial URLs in 4.4.1. It says arbitrary URLs should
be used unless they are not practical. I would say if there were no
configuration at all we could talk about whether or not they were
impractical, but in the cases that are in scope we're definitely talking
about configuration.

-P

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2018 21:30:06 +0000

> Is making it super-easy for non-technical end users to configure a new DNS server a feature or a bug?

It has been considered a feature for as long as there has been an Internet. That is, every operating system allows users to do this in the operating system. Why should browsers be different?

The question is parallel to "Is making it super-easy for non-technical end users to configure a new search engine a feature or a bug?". Some parties feel that it is a bug because users will pick a new, crappy search engine based on bad advice. Some parties feel that it is a feature because some search engines have better privacy policies than others, or have better ways of providing results, and so on.

--Paul Hoffman

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 7 Mar 2018 21:49:33 +0000

On Mar 7, 2018, at 5:11 PM, Patrick McManus <[email-masked]> wrote:
> Its logically an argument for not even using hostnames.

That is an absurd reach. If I already interact with my bank through my browser, I know its hostname. I call my bank "Bank of America", not "bofa.com", but I know the latter is its hostname.

> The minimal information in your example is your bank - so just assume www.BANK.com.

See above. In the edge case that I hear that my bank runs this secure DNS server but I don't know my bank's hostname, I am out of luck with DOH. That's fine.

> But even if you argue hostname is the goldilocks of granularity, the DNS resolver market has already shown that its not rich enough. note that quad-9 offers both 9.9.9.9 and 9.9.9.10 and that 10 is not simply a secondary for .9 but its a different service with different policies and different results.. but because the configuration scheme of traditional DNS is so coarse they needed to burn IPv4 addresses just to convey configuration information.

OS configuration for DNS service has always been based on IP addresses because using a domain name to identify a server causes a pretty obvious chicken-and-egg problem. How is that relevant for DOH, which is based on URLs that already have a hostname in them?

> Your suggestion uplevels that from 1 address to 1 hostname but the fundamental problem remains.

Which fundamental problem? My proposal allows for differentiated service in the JSON response.

> Lastly, we want this work to be consistent with the BCP56bis work which explicitly talks about Initial URLs in 4.4.1. It says arbitrary URLs should be used unless they are not practical.

And this proposal fully supports that notion. No one has to go through discovery to use the DNS API server.

> I would say if there were no configuration at all we could talk about whether or not they were impractical, but in the cases that are in scope we're definitely talking about configuration.

Correct. This proposal is to make configuration easier. Are you objecting to making configuration easier, or to the notion that the DNS API server URL should be discoverable, or ...?

--Paul Hoffman

---

From: Martin Thomson <[email-masked]>
Date: Thu, 8 Mar 2018 09:03:24 +1100

Still having trouble with this.  Think about how you interact with a
browser.  You might type "icann.org" knowing that this gets you ICANN,
and that is magically turned into "http://icann.org/" (yeah, the
missing 's' remains an embarrassing omission, but that's harder to fix
than it seems).  Fewer people do that than you think, because that's
the role that search engines fill now.  You might also type
"icann.org/dns", but even fewer do that.

Why do you believe that servicing this market in this way is such an
imperative?  Search the web, find the string you want, copy and paste.
In fact, it serves the point of separation very effectively.  If your
configuration lists "9.9.9.9" or "dns.provider.example", then the
string "https://dns.provider.example/" might signify an important
difference in how the software uses that string.  Note the huge
difference in those last two examples does not - in my opinion -
motivate the architectural violence you advocate for.

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Mar 2018 17:20:35 -0500

Hi,

> It has been considered a feature for as long as there has been an Internet. That is, every operating system allows users to do this in the operating system. Why should browsers be different?

I think I agree with Paul's sentiment there, but I am pretty sure I
disagree with his glib description of the history.  As a percentage of
Internet users, the group of people who understood what it meant to
reconfigure one's DNS resolution path has been in decline for rather a
long time, and it is often quite clear to me that even developers
working on things that might touch on the DNS have only the dimmest
grasp of how it works or what the consequences will be in fooling with
it.  Nobody has any reason to imagine that changes to their search
engine will have wide effects throughout the automatic portions of
their Internet experience, but changing your resolver certainly will
have that sort of effect in at least some cases.  I think this is an
area that needs some care, even if I agree that users need to be able
to do it.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Mar 2018 09:46:19 +1100

> On 8 Mar 2018, at 8:30 am, Paul Hoffman <[email-masked]> wrote:
> 

Sure, they're both attack vectors. I note that to configure a new search engine in most browsers, you need to type in what is effectively a URL template.

Also, we don't make decisions based upon what people feel in the IETF -- we decide based upon rough consensus and running code. Is there *any* implementer interest in what you're describing?

---

From: Justin Henck <[email-masked]>
Date: Wed, 07 Mar 2018 22:48:57 +0000

> fundamental problem remains.

As I understand the proposal, the metadata in .well-known would be
optional?  If that's the case, is this any more objectionable than
www.BANK.com <http://www.bank.com/> being interpreted as
http://www.BANK.com/ <http://www.bank.com/>, which is in turn redirected to
https://www.BANK.com/index.html <https://www.bank.com/index.html>?  It
seems to me we only gain potential use cases by having an optional
discovery endpoint, and lose nothing.

An additional use case might be DNS-over-TLS auto-upgrade if a potentially
hostile network blocks port 853.

Justin Henck
Product Manager
212-565-9811
google.com/jigsaw

PGP: EA8E 8C27 2D75 974D B357 482B 1039 9F2D 869A 117B

On Wed, Mar 7, 2018 at 5:46 PM Mark Nottingham <[email-masked]> wrote:

> > It has been considered a feature for as long as there has been an
> Internet. That is, every operating system allows users to do this in the
> operating system. Why should browsers be different?
> >
> > The question is parallel to "Is making it super-easy for non-technical
> end users to configure a new search engine a feature or a bug?". Some
> parties feel that it is a bug because users will pick a new, crappy search
> engine based on bad advice. Some parties feel that it is a feature because
> some search engines have better privacy policies than others, or have
> better ways of providing results, and so on.
>
> Sure, they're both attack vectors. I note that to configure a new search
> engine in most browsers, you need to type in what is effectively a URL
> template.
>
> Also, we don't make decisions based upon what people feel in the IETF --
> we decide based upon rough consensus and running code. Is there *any*
> implementer interest in what you're describing?
>
>
> --

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 7 Mar 2018 17:59:17 -0500

> Sure, they're both attack vectors. I note that to configure a new search engine in most browsers, you need to type in what is effectively a URL template.

Well, maybe that's part of the care would be that I suggested in
another message.

> Also, we don't make decisions based upon what people feel in the IETF -- we decide based upon rough consensus and running code. Is there *any* implementer interest in what you're describing?

If the IETF is standardising a feature that users can't get out of or
use in ways that suit them, then I would have to ask why we are
willing to touch it with a 93 1/2' pole.  That really would make us
the IVTF, and I'm not interested in such efforts.  I agree that there
is a serious attack vector in allowing users to configure doh, but
it's also an attack vector if only your vendor can control how it can
be used.  If _that's_ what we think we're building, then I at least
was fooled by the charter.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Patrick McManus <[email-masked]>
Date: Wed, 7 Mar 2018 18:03:17 -0500

I believe that the level of discovery (i.e. you need to configure it) is
fine for the work the WG has adopted and the recursive resolver scope we're
working on. It is the normal approach for a web service.

While I don't see a lot of value in starting a separate new work item on
discovery I don't have a strong opinion on whether the wg should do that
beyond my suspicion that it wouldn't be widely used.

On Wed, Mar 7, 2018 at 4:49 PM, Paul Hoffman <[email-masked]> wrote:

>
> See above. In the edge case that I hear that my bank runs this secure DNS
> server but I don't know my bank's hostname, I am out of luck with DOH.
> That's fine.
>
>
I don't understand why we are talking about your bank's DNS server.  I
presume you mean that in context only with your interactions with the bank?

I know you mentioned some use cases around the browser using it to resolve
http urls instead of its global recursive resolver, but that's not
something that is in scope for the DoH WG (that would imo best be a HTTPbis
item - as it is how to route HTTP requests.. for which one possibility
among many is to define a discovery algorithm for a DoH endpoint based on
first party and define the scope of the result from that endpoint.. but
that's speculative and nobody is chartered to do that work.)

>
> OS configuration for DNS service has always been based on IP addresses
> because using a domain name to identify a server causes a pretty obvious
> chicken-and-egg problem. How is that relevant for DOH, which is based on
> URLs that already have a hostname in them?
>

it is relevant here because your proposal effectively maps a hostname to a
URL. It kinda looks like it maps it to N URLs but because there is no
useful way to discriminate between them other than configuration (which
could just use the URL), it is effectively just one. Your example did use
redundant servers, which wouldn't really need discrimination other than
perf/reachability, but the web already has plenty of ways of building
redundancies into unique urls and its ideal if the url descirbes the
resource, not the routing,

[..]

>
> Correct. This proposal is to make configuration easier. Are you objecting
> to making configuration easier, or to the notion that the DNS API server
> URL should be discoverable, or ...?
>
>
I'm definitely saying the DoH protocol doc does not need to further define
discovery.

---

From: Patrick McManus <[email-masked]>
Date: Wed, 7 Mar 2018 18:10:46 -0500

> was fooled by the charter.

I think we all support configuration by URL. Paul is simply advocating for
an optional layer of indirection in discovering that URL (and please
correct me if I'm wrong on that). I don't think that would have a material
impact on what products would allow configuration and which wouldn't
(though it obviously could impact how)...

---

From: Mark Nottingham <[email-masked]>
Date: Thu, 8 Mar 2018 10:41:47 +1100

> On 8 Mar 2018, at 9:59 am, Andrew Sullivan <[email-masked]> wrote:
> 

I meant something more specific -- are any implementations (practically, browsers) keen to expose a UX that allows you to type an arbitrary hostname into it and wind up resolving DNS through that host, and can explain their reasons for doing so with a hostname rather than a URL (which again is how search engines are configured currently)?

We generally don't discuss UX in the IETF, but it seems like if we're going to have a UX-driven argument determining the protocol, we should at least have someone who's interested in following that path and can explain why this so important. Otherwise it feels too much like engineers who have no business making UX decisions taking a punt.

And that still doesn't address the mismatch with the intended use of .well-known.

Regards,

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Thu, 8 Mar 2018 16:58:53 +0100

On Thu, Mar 08, 2018 at 09:46:19AM +1100,
 Mark Nottingham <[email-masked]> wrote 
 a message of 24 lines which said:

> I note that to configure a new search engine in most browsers, you
> need to type in what is effectively a URL template.

I would thought that almost all "M. Smith" users use (without knowing
it) OpenSearch, thus have no URL to type?

<link rel="search"
           type="application/opensearchdescription+xml" 
           href="/misc/add-search-engine.xml"
           title="Beautiful site" />

This reminds me I should harass [email-masked] for an OpenSearch description.