Re: [Add] A proposed charter for ABCD

[Vittorio Bertola <[e-mail]>]

Thanks for putting this together, and see comments below.

Il 20/12/2019 16:20 Ben Schwartz <bemasc=[e-mail]> ha scritto:

Proposed charter text:

This working group will focus on DNS client side topics, particularly discovery and selection of resolvers. This complements existing DNS-related working groups, which are responsible for improvements to the DNS protocol itself, and for operational questions that are principally of interest to DNS server operators.

The working group is chartered to develop an extensible protocol for a DNS client to learn detailed information about a resolver, based on draft-ietf-dnsop-resolver-information, which will be transferred from dnsop. 

I think that one actual problem that many here would like to solve is: for decades we have been discovering and using the local network-provided resolver as a default, we would like to continue doing that but with an encrypted local resolver, how do we do that? This draft charter seems to assume that the client will discover the unencrypted local resolver through the currently existing protocols, leaving this phase out of scope, and then will use a new method, to be developed and in scope for this group, to find out the encrypted local resolver that matches the unencrypted one. But are we already sure that this is the best solution for the problem, rather than developing something new that does both things at the same time? Otherwise, the mission above should also include, at least as an option, the discovery of locally available encrypted resolvers.

Relying on this new protocol where appropriate, the working group should produce standards-track, informational, or experimental documents that provide the following items, using the drafts in brackets as input (with no obligation to adopt them): * methods for a recursive resolver to advertise support for an alternative transport protocol [draft-sah-resinfo-doh],
 * methods for a recursive resolver to indicate that it will sometimes return DNS results that are different from the global DNS [draft-grover-add-policy-detection],

Building on what I said above, I will point out that conceptually users are not interested in a resolver's policy, but rather in the local network's policy, i.e. conditions, restrictions and safeguards to Internet access effected by the network's owner via DNS. So it is useless to have the capability for a resolver to indicate policy, if there is not also the capability for a client to discover that that resolver exists and is able to provide information on the local network's policy.

 * methods for improving user privacy by avoiding DNS queries that leak information or directing them to a server that will have this information anyway [draft-pauly-dprive-adaptive-dns-privacy],

I am still not convinced that the concept in that draft "improves user privacy". Can we please avoid giving that for granted?

Also, more generally, the idea of using many resolvers at once, rather than a single one, opens several cans of worms in policy and legal terms, and possibly even in terms of "security & stability" (in the ICANN sense). Perhaps the IETF should stop working on new technical developments just because it can, and assess the non-technical implications of these new developments before working on them.

and * a format for describing the client’s DNS configuration, suitable for diagnostics and debugging.

Where possible, any mechanisms that specify exchange of information between clients and resolvers should provide the security properties expected of IETF protocols, e.g., confidentiality protection, integrity protection, and authentication with strong work factor.  Each specification must clearly indicate under what circumstances and assumptions these properties are or are not provided.

This is not only true of security, but also of privacy - some mechanisms could provide more or less of it depending on the assumptions and on the privacy threat model, and this should also be discussed.

There should also be work on documenting the existing use cases and services that consumer DNS resolvers provide, so that one could see whether the assumptions above are met in real world situations or not.

--

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[e-mail] 
Office @ Via Treviso 12, 10144 Torino, Italy