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

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

On Thu, 21 May 2020 at 00:04, Tommy Pauly <tpauly=40apple.com@dmarc.ietf.org>
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:
> - 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
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>