Subject: [Add] New draft: draft-pauly-add-resolver-discovery

From: Tommy Pauly <[email-masked]>
Date: Wed, 20 May 2020 16:03:44 -0700

Hello ADD,

We’ve just posted a draft of Adaptive DNS Privacy [1] that’s scoped down to talk about resolver discovery and designation mechanisms, both on local networks and over the wider Internet. This draft is targeted at the focus of the ADD group.

https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00 <https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00>

This covers:
- What it means to designate an encrypted resolver
- How to discover resolvers using SVCB/HTTPSSVC records
- How to validate designation either by validating DNSSEC on these records, or by performing validation with an HTTPS server
- How to advertise a resolver on the local network
- How to discover a “companion” DoH server to a directly known resolver

Thanks to Tommy Jensen for his additional input on some of the local/direct resolver bootstrapping.

We’ll be publishing other documents that update the behavior for client algorithms and the use of Oblivious DoH, but we wanted to present this portion individually as the group discusses how best to discover resolvers, etc.

Best,
Tommy

[1] Previous, broader version, here: https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 26 May 2020 21:03:17 -0400

Thanks for making a simplified form of the proposal to get started.

Section 3.1:

How do you expect TTLs to work?  If the dohuri expires along with the SVCB
record that delivered it, is that actually useful?

More generally, I think this section is extremely close to
https://tools.ietf.org/html/draft-tapril-ns2-00, which is trying to
enable recursive->authoritative DoH.  We should aim for a unified, or at
least coordinated solution to these closely related problems.

Section 3.2:
>   Designated Resolvers that support DoH SHOULD provide a PvD JSON
>   dictionary available at the well-known PvD URI with the path of the
>   DoH server's URI template appended.

Strictly speaking, "https://example.com{/dns}/foo?bar=baz" is a valid DoH
URI template, but it doesn't have a well-defined path.  I think the best
option is probably to encode all DoH PvDs on one origin into a single JSON
object at a fixed well-known location, with the full template as the
top-level key.

With dnsZones, is the idea to enable authenticated split-horizon networks?
The PvD draft defines "dnsZones" but offers no explanation of its
semantics, so I'm having trouble figuring out the intended deployment here.

Section 5:
I think this is an interesting idea, but to comply with SVCB semantics I
would structure this as an SVCB query for dns://resolver.arpa, i.e.  at
_dns.resolver.arpa.  This would resolve to an SVCB RRSet that can enumerate
alternative endpoints with different protocols and parameters.  (This is
again similar to the NS2 proposal.)

I don't understand the motivation for using IP hints in this way.  Normal A
and AAAA records would seem to suffice, and are likely easier to maintain.

I don't understand why you require the IP address to appear in the
certificate.  This would prevent resolvers from directing users to a
trusted third party, creates a fragile binding between the insecure and
secure resolver deployments (e.g. when changing the resolver's IP address),
and rules out this mechanism entirely for home router type configurations.

On Wed, May 20, 2020 at 7:04 PM Tommy Pauly <tpauly=
[email-masked]> wrote:

> Hello ADD,
>
> We’ve just posted a draft of Adaptive DNS Privacy [1] that’s scoped down
> to talk about resolver discovery and designation mechanisms, both on local
> networks and over the wider Internet. This draft is targeted at the focus
> of the ADD group.
>
> https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00
>
> This covers:
> - How to validate designation either by validating DNSSEC on these
> records, or by performing validation with an HTTPS server
> We’ll be publishing other documents that update the behavior for client
> algorithms and the use of Oblivious DoH, but we wanted to present this
> portion individually as the group discusses how best to discover resolvers,
> etc.
>
> Best,
> Tommy
>
> [1] Previous, broader version, here:
> https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01
> --
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add
>

---

From: Tommy Jensen <[email-masked]>
Date: Thu, 28 May 2020 02:49:18 +0000

Hey Ben,

Thank you for your feedback! For Section 5:

> I would structure this as an SVCB query for dns://resolver.arpa, i.e.  at _dns.resolver.arpa.

This makes sense; I'll give it more thought.

> I don't understand the motivation for using IP hints in this way.  Normal A and AAAA records would seem to suffice, and are likely easier to maintain.

The thinking here was the multiple record case. If there are two SVCB records returned to designate two DoH servers that are equivalent, then having the hints in the record itself makes the mapping more clear than sending back two As and two AAAAs along with some mapping logic. Additionally, I think the named parameter context helps keep it future proof in case future versions specify a second use of IP addresses within the record where A/AAAA would be ambiguous.

> I don't understand why you require the IP address to appear in the certificate.  This would prevent resolvers from directing users to a trusted third party,

This is very much by design. As a stub resolver, I cannot tell the difference between "classic DNS server foo recommends DoH server bar" and "classic DNS server foo recommends DoH server bad-actor" thanks to a MitM. If the IP addresses of both resolvers aren't in the DoH server cert, then there isn't a way to validate the claim made over classic DNS that the DoH server can serve the same needs the classic resolver can. With this requirement in place, an on-path attacker could still prevent upgrade to DoH by dropping packets (as with any DoH bootstrap starting only with classic DNS), but couldn't redirect stubs to a rogue DoH server.

> creates a fragile binding between the insecure and secure resolver deployments (e.g. when changing the resolver's IP address),

Fair point. This does place a new burden on resolver admins.

> and rules out this mechanism entirely for home router type configurations.

Not entirely, as not all ISPs hand out RFC1918 addresses. However, if the router is advertising RFC1918 addresses for DNS use, then yes, this mechanism won't help. Given ownership of an RFC1918 address isn't verifiable like a public address is, I think it would be preferable for the stub resolver to get the encrypted DNS configuration directly from the same source as it would get the classic DNS address today, such as through PvDs.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Ben Schwartz <bemasc=[email-masked]>
Sent: Tuesday, May 26, 2020 6:03 PM
To: Tommy Pauly <tpauly=[email-masked]>
Cc: ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] New draft: draft-pauly-add-resolver-discovery

Section 3.1:

How do you expect TTLs to work?  If the dohuri expires along with the SVCB record that delivered it, is that actually useful?

More generally, I think this section is extremely close to https://tools.ietf.org/html/draft-tapril-ns2-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-tapril-ns2-00&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C2900c450afe04b92178108d801d9cd51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261382264817197&sdata=QRHc9F%2B7FK5iN90A92718soe5CFOFbHzOAietes%2FasE%3D&reserved=0>, which is trying to enable recursive->authoritative DoH.  We should aim for a unified, or at least coordinated solution to these closely related problems.

>   DoH server's URI template appended.

Strictly speaking, "https://example.com<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fexample.com%2F&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C2900c450afe04b92178108d801d9cd51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261382264817197&sdata=qbHzdj8iip3hIwGCCQEKsqMrIo4c%2F4sdI0WaB67vb5g%3D&reserved=0>{/dns}/foo?bar=baz" is a valid DoH URI template, but it doesn't have a well-defined path..  I think the best option is probably to encode all DoH PvDs on one origin into a single JSON object at a fixed well-known location, with the full template as the top-level key.

With dnsZones, is the idea to enable authenticated split-horizon networks?  The PvD draft defines "dnsZones" but offers no explanation of its semantics, so I'm having trouble figuring out the intended deployment here.

Section 5:
I think this is an interesting idea, but to comply with SVCB semantics I would structure this as an SVCB query for dns://resolver.arpa, i.e.  at _dns.resolver.arpa.  This would resolve to an SVCB RRSet that can enumerate alternative endpoints with different protocols and parameters.  (This is again similar to the NS2 proposal.)

I don't understand the motivation for using IP hints in this way.  Normal A and AAAA records would seem to suffice, and are likely easier to maintain.

I don't understand why you require the IP address to appear in the certificate.  This would prevent resolvers from directing users to a trusted third party, creates a fragile binding between the insecure and secure resolver deployments (e.g. when changing the resolver's IP address), and rules out this mechanism entirely for home router type configurations.

On Wed, May 20, 2020 at 7:04 PM Tommy Pauly <tpauly=[email-masked]<mailto:[email-masked]>> wrote:
Hello ADD,

https://tools.ietf.org/html/draft-pauly-add-resolver-discovery-00<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pauly-add-resolver-discovery-00&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C2900c450afe04b92178108d801d9cd51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261382264827151&sdata=ldPqxbKsco2nuKkxa%2BSMDu%2BiOQHtTjRMj1k5W48AK1M%3D&reserved=0>

This covers:

We’ll be publishing other documents that update the behavior for client algorithms and the use of Oblivious DoH, but we wanted to present this portion individually as the group discusses how best to discover resolvers, etc..

Best,
Tommy

[1] Previous, broader version, here: https://tools.ietf.org/html/draft-pauly-dprive-adaptive-dns-privacy-01<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-pauly-dprive-adaptive-dns-privacy-01&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C2900c450afe04b92178108d801d9cd51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261382264837106&sdata=xfTWfR36I0kqDaNd%2FdT2WvzZLuffO0c%2FmJARKc84wDM%3D&reserved=0>
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C2900c450afe04b92178108d801d9cd51%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637261382264837106&sdata=r5J5nq0J4wlyg46%2FqB8y34eP5ArjauYc%2Bo7tiJDfzDk%3D&reserved=0>

---

From: "Chris Box (BT)" <[email-masked]>
Date: Fri, 29 May 2020 17:43:02 +0100

Thanks to the authors for this new draft. Having now read it, I'd like to
raise a few points for discussion.

*Section 3 Designated Resolvers*
This states

   Note that clients MUST NOT accept designations for effective top-
   level domains (eTLDs), such as ".com".
This can be hard to define, and I know there's a history of problems in
this space, so it feels like it requires a normative reference.
Would this be the best one?
https://httpwg.org/http-extensions/draft-ietf-httpbis-rfc6265bis.html#terminology
If so, should it be renamed from "eTLDs" to "Public Suffixes"?

*3.2 Additional Designation with PvD JSON*
   Names that are listed in the "dnsZones" key in the JSON dictionary
   indicate other names that designate the resolver.  For each of those
   domains, clients SHOULD issue an SVCB query to the DoH resolver.

I would prefer to have some guidance in here about the number of dnsZones
that are considered reasonable to list (10? 20? 50?). And also clarify that
clients can form their own view on which of these should result in a SVCB
query.

Perhaps the client could use the knowledge that SVCB answers might be
cached by its own OS and deal with those first, before then issuing
external queries for up to "n" zones that it thinks are the most likely to
be required? And perhaps we could guide the creator of the PvD that they
should return dnsZones ordered by likely popularity, from most to least?

*3.3 Mutual Confirmation with PvD JSON*
   Clients MUST validate the resolver designation by checking a resource
   hosted by the name indicated in "trustedNames".  The client first
   issues an HTTP GET request by appending "/.well-known/pvd" to the
   trusted name, using the "https" scheme.

If a Pvd claims to be designated for 10 dnsZones, and adds that all 10 are
also trustedZones, what should the client do? It sounds like it should send
10 SVCB queries, but if they are not validly signed, it should then follow
up with 10 GETs (each of which may in turn need A/AAAA queries). Or do you
envisage a different algorithm?

*References to whitelisting*
Section 6.3: Clients can also choose to only whitelist DoH servers that are
associated with many names.
Section 8: Such risk can be mitigated by further restricting the list of
resolvers that are whitelisted for direct use based on client policy.

It feels odd that whitelisting is mentioned in this draft but there is no
narrative on how it might work, and what it would need to take into
consideration. Do you intend to cover this in the separate document that
updates client behaviour?

Thanks,
Chris