Re: [Add] [EXTERNAL] Re: New draft: draft-pauly-add-resolver-discovery

[Tommy Jensen <[e-mail]>]

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 <[e-mail]> on behalf of Ben Schwartz <bemasc=[e-mail]>
Sent: Tuesday, May 26, 2020 6:03 PM
To: Tommy Pauly <tpauly=[e-mail]>
Cc: ADD Mailing list <[e-mail]>
Subject: [EXTERNAL] Re: [Add] New draft: draft-pauly-add-resolver-discovery

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<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.

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<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=[e-mail]<mailto:[e-mail]>> 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<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:
- 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<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
[e-mail]<mailto:[e-mail]>
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>