Subject: [Doh] Seeking input on draft-03

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Feb 2018 13:05:11 -0500

Hi all,

The authors of draft-ietf-doh-dns-over-https have been making good
progress, and a draft-03 is now ready with several changes and
clarifications.

One important difference is that draft-03 no longer proposes a
".well-known" entry.  In draft-02 and prior, clients could check for the
presence of a DOH service at the default path, given only the domain name
of a server.  In draft-03, there is no default path, so clients must be
configured with the full URL of the DOH endpoint.

Is this change compatible with your use cases?  Would this alter the way
users interact with your systems?  How do you think DOH client
configuration should work?

Please respond with your thoughts,
Ben Schwartz

---

From: Mike Bishop <[email-masked]>
Date: Thu, 8 Feb 2018 18:11:05 +0000

I’m inclined to think this is a positive change.  We’re trying to do something better than the current world of “trust the local DNS server because unauthenticated DHCP says so”, and promiscuous trust just because a server claims it support DOH via a .well-known endpoint isn’t really any better.  The client should know the hostname(s) of the DOH server(s) it wants to use, and it should authenticate the DOH server against that hostname.  If a server hosts content and also wants to also serve DOH, there are ways to present a hostname that covers both names (or present two certificates) on an HTTP connection.

From: Doh [mailto:[email-masked]] On Behalf Of Ben Schwartz
Sent: Thursday, February 8, 2018 10:05 AM
To: [email-masked]
Subject: [Doh] Seeking input on draft-03

Hi all,

The authors of draft-ietf-doh-dns-over-https have been making good progress, and a draft-03 is now ready with several changes and clarifications.

One important difference is that draft-03 no longer proposes a ".well-known" entry.  In draft-02 and prior, clients could check for the presence of a DOH service at the default path, given only the domain name of a server.  In draft-03, there is no default path, so clients must be configured with the full URL of the DOH endpoint.

Is this change compatible with your use cases?  Would this alter the way users interact with your systems?  How do you think DOH client configuration should work?

---

From: Paul Hoffman <[email-masked]>
Date: Thu, 8 Feb 2018 18:18:15 +0000

On Feb 8, 2018, at 10:11 AM, Mike Bishop <[email-masked]> wrote:
> I’m inclined to think this is a positive change.  We’re trying to do something better than the current world of “trust the local DNS server because unauthenticated DHCP says so”, and promiscuous trust just because a server claims it support DOH via a .well-known endpoint isn’t really any better.  The client should know the hostname(s) of the DOH server(s) it wants to use, and it should authenticate the DOH server against that hostname.

To be clear: that's not what the current draft says. It says that the client needs to know *the full URL to the DOH service* of the DOH server it wants to use.

The effect of this is that, if a user wants to tell its browser to use DOH on example.com, they need to know the full URL and type it into some config dialog for the browser. Or, possibly worse, browsers that want to enable DOH will have to have a list of popular DOH servers and the URL associated with each server, somewhat akin to the preloaded key pinning we see now; that list would also need to allow the user to extend the list.

Using .well-known/ or some other fixed prefix would make it so that configuring DOH was less onerous for users.

--Paul Hoffman

---

From: Ben Schwartz <[email-masked]>
Date: Thu, 8 Feb 2018 13:21:23 -0500

On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <[email-masked]> wrote:

> I’m inclined to think this is a positive change.  We’re trying to do
> something better than the current world of “trust the local DNS server
> because unauthenticated DHCP says so”, and promiscuous trust just because a
> server claims it support DOH via a .well-known endpoint isn’t really any
> better.
>

To be clear, the draft never proposed promiscuous trust, which would indeed
be highly problematic.  However, draft-03 does include additional language
clarifying this point.

> The client should know the hostname(s) of the DOH server(s) it wants to use
>

In draft-03, "knowing the hostname" is not sufficient, because there is no
default path for DOH.  This is the change on which I am seeking input.

> , and it should authenticate the DOH server against that hostname.
>

Yes, definitely.  (I believe the draft is clear on this point, but feel
free to suggest improvements.)

>   If a server hosts content and also wants to also serve DOH, there are
> ways to present a hostname that covers both names (or present two
> certificates) on an HTTP connection.
>
>
>
> *From:* Doh [mailto:[email-masked]] *On Behalf Of *Ben Schwartz
> *Sent:* Thursday, February 8, 2018 10:05 AM
> *To:* [email-masked]
> *Subject:* [Doh] Seeking input on draft-03
>
>
>
> Hi all,
>
>
>

---

From: Justin Henck <[email-masked]>
Date: Thu, 08 Feb 2018 18:55:50 +0000

I would like to see a way for clients to discover a DNS server hosted on a
certain domain.  Perhaps a .well-known/dns path that contains a relative
pointer and other metadata.  I'm imagining a use case whereby the user
could choose to rely upon an organization that they find trustworthy which
is offering DNS, without needing to do a significant amount of discovery
(e.g. "maybe known.tld has a DNS server?").  You could of course also have
an absolute pointer, but then you have to account for the situation whereby
known.tld might delegate to unknown.tld.

Justin Henck
Google

On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz <[email-masked]> wrote:

> To be clear, the draft never proposed promiscuous trust, which would
> indeed be highly problematic.  However, draft-03 does include additional
> language clarifying this point.
>
>
> _______________________________________________
> Doh mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/doh
>

---

From: Erik Kline <[email-masked]>
Date: Thu, 8 Feb 2018 10:58:59 -0800

Sounds like you might want a (TXT) record at the zone cut level?

On 8 February 2018 at 10:55, Justin Henck <[email-masked]> wrote:
> pointer and other metadata.  I'm imagining a use case whereby the user could
> choose to rely upon an organization that they find trustworthy which is
> offering DNS, without needing to do a significant amount of discovery (e.g.
> "maybe known.tld has a DNS server?").  You could of course also have an
> absolute pointer, but then you have to account for the situation whereby
>>> presence of a DOH service at the default path, given only the domain name of
>>> a server.  In draft-03, there is no default path, so clients must be
>>> users interact with your systems?  How do you think DOH client configuration
>>> should work?
>>>
>>>
>>>

---

From: Justin Henck <[email-masked]>
Date: Thu, 08 Feb 2018 19:16:56 +0000

That would work for the situation I specified, but I think that a
.well-known pointer provides the additional benefit of serving more
technical users with an advanced configuration. (It is also in-line with
the intended use of .well-known as I understand RFC 5785.)

Specifically, if an implementer creates an advanced setting whereby you can
configure a DOH server with both a domain and an IP (to eliminate the need
for bootstrapping) then you have made the user's life easier. And, although
a URI is not supposed to change, a .well-known/dns pointer requirement
would ensure that capricious servers don't break manually-configured
clients.

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

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

On Thu, Feb 8, 2018 at 1:59 PM Erik Kline <[email-masked]> wrote:

> could

---

From: manu tman <[email-masked]>
Date: Thu, 8 Feb 2018 11:19:13 -0800

On Thu, Feb 8, 2018 at 10:55 AM, Justin Henck <[email-masked]> wrote:

> pointer and other metadata.
>

https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/75 touches on
discoverability.

I am more in favor of a set of simple requirements, so simple client and
server implementation can exist and provide the basics of DOH
functionality.
Optionally, discovery can be used to be more fancy and provide
extensibility, but at the core of it, I would expect that knowing a domain
and optionally an IP (to avoid the chicken and egg issue of being able to
resolve the DOH server IP ) should be enough to be able to access DNS over
HTTPS using GET at a well known endpoint.
Enforcing discovery will most likely slow and prevent new implementations.

Manu

> I'm imagining a use case whereby the user could choose to rely upon an
> organization that they find trustworthy which is offering DNS, without
> needing to do a significant amount of discovery (e.g. "maybe known.tld has
> a DNS server?").  You could of course also have an absolute pointer, but
> then you have to account for the situation whereby known.tld might delegate
> to unknown.tld.
>
> Justin Henck
> Google
>
>
>> In draft-03, "knowing the hostname" is not sufficient, because there is
>> no default path for DOH.  This is the change on which I am seeking input.
>>
>>

---

From: "Hewitt, Rory" <[email-masked]>
Date: Thu, 8 Feb 2018 19:22:24 +0000

Additionally, using /.well-known/ would allow for URI Template discovery, if required - client retrieves URI Template from e.g. /.well-known/doh.template and then uses that to build DNS request URI.

See  <https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74> https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74 for @mnot's suggestion.

Thanks,

Rory

Rory Hewitt

Senior Solutions Architect

Global Services & Support

Akamai Technologies

Tel: (408) 650-0035

From: Justin Henck [mailto:[email-masked]] 
Sent: Thursday, February 8, 2018 11:17 AM
To: [email-masked]
Cc: Ben Schwartz <[email-masked]>; [email-masked]; [email-masked]
Subject: Re: [Doh] Seeking input on draft-03

That would work for the situation I specified, but I think that a .well-known pointer provides the additional benefit of serving more technical users with an advanced configuration. (It is also in-line with the intended use of .well-known as I understand RFC 5785.)

Specifically, if an implementer creates an advanced setting whereby you can configure a DOH server with both a domain and an IP (to eliminate the need for bootstrapping) then you have made the user's life easier. And, although a URI is not supposed to change, a .well-known/dns pointer requirement would ensure that capricious servers don't break manually-configured clients.

  <https://www.gstatic.com/jigsaw/Jigsaw_logo.png> 

Justin Henck 
Product Manager 

212-565-9811 

 <https://urldefense.proofpoint.com/v2/url?u=https-3A__google.com_jigsaw&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=N-RLQbYhldj1naDovU3jQQtWdiNb5pbKuxXJJ3p663Y&e=> google.com/jigsaw

On Thu, Feb 8, 2018 at 1:59 PM Erik Kline <[email-masked] <mailto:[email-masked]> > wrote:

On 8 February 2018 at 10:55, Justin Henck <[email-masked] <mailto:[email-masked]> > wrote:
> On Thu, Feb 8, 2018 at 1:21 PM Ben Schwartz <[email-masked] <mailto:[email-masked]> > wrote:
>>
>> On Thu, Feb 8, 2018 at 1:11 PM, Mike Bishop <[email-masked] <mailto:[email-masked]> > wrote:
>>>
>>> From: Doh [mailto:[email-masked] <mailto:[email-masked]> ] On Behalf Of Ben Schwartz
>>> To: [email-masked] <mailto:[email-masked]> 
>> [email-masked] <mailto:[email-masked]> 
>> https://www.ietf.org/mailman/listinfo/doh <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=> 
>
>
> [email-masked] <mailto:[email-masked]> 
> https://www.ietf.org/mailman/listinfo/doh <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=> 
>

---

From: Justin Henck <[email-masked]>
Date: Thu, 08 Feb 2018 19:23:56 +0000

> HTTPS using GET at a well known endpoint.

I may be misunderstanding, but doesn't this imply either a fixed path, or a
discoverable path via another (e.g. .well-known/dns)?

On Thu, Feb 8, 2018 at 2:22 PM Hewitt, Rory <[email-masked]> wrote:

> Additionally, using /.well-known/ would allow for URI Template discovery,
> if required - client retrieves URI Template from e.g.
> /.well-known/doh.template and then uses that to build DNS request URI.
>
>
>
> See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74 for
> @mnot's suggestion.
>
>
>
> Thanks,
>
>
>
> Rory
>
>
>
> *Rory Hewitt*
>
> *From:* Justin Henck [mailto:[email-masked]]
> *Sent:* Thursday, February 8, 2018 11:17 AM
> *To:* [email-masked]
> *Cc:* Ben Schwartz <[email-masked]>; [email-masked]; [email-masked]
> *Subject:* Re: [Doh] Seeking input on draft-03
>
>
>
> Specifically, if an implementer creates an advanced setting whereby you
> can configure a DOH server with both a domain and an IP (to eliminate the
> need for bootstrapping) then you have made the user's life easier. And,
> although a URI is not supposed to change, a .well-known/dns pointer
> requirement would ensure that capricious servers don't break
> manually-configured clients.
>
>
>
>
> *Justin Henck*
> Product Manager
>
> 212-565-9811
>
> google.com/jigsaw
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__google.com_jigsaw&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=N-RLQbYhldj1naDovU3jQQtWdiNb5pbKuxXJJ3p663Y&e=>
>
>
>
> no
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=>
> >
> >
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_doh&d=DwMFaQ&c=96ZbZZcaMF4w0F4jpN6LZg&r=h4goE6gK_ZaRrvwi4Hglaq0NyaBCb3I3XALyazxKb6w&m=KrH6cYm-gcGpqevreKzpdpsMm-hErKTCNEthg2TBsTU&s=T69zw0O8NFcgM07c8aK0knaf9RoDeSYGFdN_MXSy4a4&e=>
> >
>
>

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 8 Feb 2018 19:56:57 +0000

> configured with the full URL of the DOH endpoint.

Apologies if I'm forgetting a thread where this was discussed,
but what's the reason for dropping .well-known? (If there is a
thread, a pointer to that is a sufficient answer.)

Thanks,
S.

-- 
PGP key change time for me.
New-ID 7B172BEA; old-ID 805F8DA2 expires Jan 24 2018.
NewWithOld sigs in keyservers.
Sorry if that mucks something up;-)

---

From: Patrick McManus <[email-masked]>
Date: Thu, 8 Feb 2018 15:24:17 -0500

WRT the removal of .wk:

* its previous presence had never been meant as a discovery mechanism of
the form "I know a hostname, therefore I know the URL". origin is a
security primitive for http, but its not an addressing primitive for http
services such as a DoH endpoint.. indeed the DoH server might sensibly wish
to offer multiple URIs on the same host (in the same way some free dns
providers make a variety of resolution policies available with different IP
addresses).  The configuration primitive for a DoH server is the URI - not
origin.

* I had originally included .wk as a bit of future proofing for a use case
not part of the DoH charter (not to enable it, but being sure not to
preclude it at a later time). I have been convinced that .wk is not
necessary for that - and so it was removed from the draft. I regret that
these two things were confused by readers of <= -02 due to my own
composition skills (or lack thereof).

As to Stephen's query - this was both discussed f2f in singapore and
https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/24 . Of
course there hasn't been consensus declared on the issue - the editors are
just trying to make the newer drafts as closely aligned with the group's
discussion as we can manage as part of the process.

-P

---

From: manu tman <[email-masked]>
Date: Thu, 8 Feb 2018 13:36:11 -0800

On Thu, Feb 8, 2018 at 11:23 AM, Justin Henck <[email-masked]> wrote:

> I may be misunderstanding, but doesn't this imply either a fixed path, or
> a discoverable path via another (e.g. .well-known/dns)?
>

Yes, I mean to have a fixed well-known path that provides DOH service (as
in actual DNS queries) that can be used universally. So, any clients, given
a domain, can use DOH without having to go through the steps of service
discovery indirections.
What I understood from you original comment was to use this as an entry
point to discover alternate locations, delegation... I think it is worth it
but should be optional.

At the end of the day, either accessing a discovery endpoint or DOH service
endpoint, the client will need to be told where to get it. Having a
predefined entry point would make this easier.

>> 212-565-9811 <(212)%20565-9811>
>>
>> google.com/jigsaw
>> >>> The client should know the hostname(s) of the DOH server(s) it wants
>> to
>> >>> use
>> >>
>> >>

---

From: Justin Henck <[email-masked]>
Date: Thu, 08 Feb 2018 22:55:14 +0000

> point to discover alternate locations, delegation... I think it is worth it

Got it.  I understand the desire for simplicity, and would also prefer to
avoid complex solutions.  My specific goal is to enable users to reliably
and easily configure a trusted DOH server of their choice without
bootstrapping.

On Thu, Feb 8, 2018 at 4:36 PM manu tman <[email-masked]> wrote:

> At the end of the day, either accessing a discovery endpoint or DOH
> service endpoint, the client will need to be told where to get it. Having a
>>> Additionally, using /.well-known/ would allow for URI Template
>>> discovery, if required - client retrieves URI Template from e.g.
>>> See https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/74
>>> for @mnot's suggestion.
>>>
>>>
>>>
>>> Thanks,
>>>
>>>
>>>
>>> Rory
>>>
>>>
>>>
>>> *Rory Hewitt*
>>>

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 9 Feb 2018 09:23:53 +0000

Thanks Patrick,

> to offer multiple URIs on the same host (in the same way some free dns

Fair point.

> https://github.com/dohwg/draft-ietf-doh-dns-over-https/issues/24 . Of

I read that and it's overall convincing enough for me.

I do also wonder about the point raised there about doing surveys of
doh deployments - as one poster (willscott) said though, I'm not sure
if I think enabling that is a good thing or not. (The downside being
that censors discover deployments too.) I'd not argue that's reason
enough to retain well-known in the draft.

Cheers,
S.

> discussion as we can manage as part of the proces> -P
> 
>

---

From: Justin Henck <[email-masked]>
Date: Fri, 09 Feb 2018 15:04:14 +0000

I can still see a lot of use cases for allowing discovery with just the
origin, and think it's an important feature to allow both performance
enhancements and drive user adoption:

   - Without the need for additional standards, a client on an HTTP/2
   connection could discover a DNS resolver on that origin and use it for all
   queries related to content on that origin
   - If the certificate frame is adopted, a client could make DNS queries
   to all open connections, to see if they host an origin (preventing
   round-robin DNS from messing up multiplexing)
   - People can configure a bootstrapping-free DNS server with fewer
   variables (IP + origin)
   - People can survey DNS servers, even if the dns endpoint itself is
   access-restricted. This would allow us to track adoption, and though it
   could be used to block servers it could also be used to find ones returning
   non-canonical results.

It may be that .well-known/dns metadata would solve many of these purposes
by being optional, or by only being required to point to at least one
instance; that would account for the desire to host multiple resolvers.