Re: [Add] A proposed charter for ABCD

[Rob Sayre <[e-mail]>]

On Fri, Dec 20, 2019 at 7:20 AM Ben Schwartz <bemasc=
[e-mail]> wrote:

>
> -----------------------------------
>
> 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.  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],
>  * 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], 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.
>

It seems like the key difference between this proposal and Tommy Pauly's is
the "Where possible," at the start of the paragraph detailing security
properties. However, last I checked, these properties are not optional in
IETF protocols. Several of the proposals above look like they'll hinge on
this turn of phrase, so I don't think it's wise to punt on the
justification here. It should probably be in the charter with alongside
each work item, each of which should be more concrete. In some cases, it's
difficult to argue that these drafts make things worse, but those that
enable a downgrade from encrypted traffic are difficult to distinguish from
attacks.

In secure deployments, the network operator will be able to bootstrap DNS
(via enterprise policy, parental control software, etc). For situations
where the device is not controlled by the network, methods of
authenticating the DNS server seem called for. Since the client
(application or OS) needs to rely on the DNS for software updates to keep
it secure, it doesn't seem like Web PKI provides adequate guarantees.
Something like OIDC seems more appropriate for large-scale deployments,
where managing each client is difficult to do (example: authenticate your
ISP with OS or Browser Single Sign-In).

One possible work item for the group might be to document the security of a
variety of DNS bootstrapping options, starting from the bottom: unencrypted
DNS learned via DHCP.

thanks,
Rob