Re: [Add] Proposed charter and BoF request for IETF 106

[Eric Rescorla <[e-mail]>]

Barry,

I took a first look at your proposed ABCD charter. Thanks for
proposing something.

At a high level, I think there are some good areas for discussion
here, but they're going to get swamped by the inclusion of a bunch of
contentious topics we're not likely to get resolution on.

I think this would be much stronger if it focused entirely
on technical matters on which there is at least some agreement,
specifically:

- Signalling that the network has DoH support, who provides it,
  and (potentially) what their policies are.

- Signaling that the network has some kind of filtering policy
  that might make the application think twice about using
  DoH.

- Something like the apple proposal that does "steering" of
  traffic to the right resolver.

Note that these mechanisms should generally not tell apps what
policies they should follow when they see these signals.


These seem to be on your list below. I think we should stay away from
anything that is about specifying best current practices because as
far as I can tell all but the most trivial ones (here is how to safely
run a TLS server or something) are contested. For instance, even
retention period has very strong views on both sides.


> Together, these developments may represent
> a set of shifts depending on how the new protocols are deployed: from
> cleartext to encrypted transports; from use of unique port numbers for
> DNS resolution to ports that support significant other traffic (e.g.,
> HTTPS); from network operator control of DNS configuration to control by
> clients, third-party resolvers, or others; and from the use of a large,
> dispersed set of network operator resolvers to a smaller set of more
> centralized resolvers operated by other parties.

The word "may" is doing a lot of work here. In particular, while I
realize that this centralization argument has been repeatedly raised,
it's not really a point of consensus. Consider that in the United
States, the ISP market is dominated by a very small number of players,
with two companies, Charter and Comcast, having the vast majority of
the market
(
https://www.statista.com/statistics/217348/us-broadband-internet-susbcribers-by-cable-provider/
)
Because residential customers generally use the ISP resolver, this
market is already highly centralized. It's true that there are a lot
of much smaller enterprise resolvers, but every major
application-level DNS rollout I have seen proposed attempts to
preserve that situation.



> This potential set of shifts raises many questions given the long history
> and current status of DNS operational practices. Network operators have
> historically used DNS services for a variety of purposes beyond simple
> query resolution: to mitigate network and security threats, to enforce
> enterprise policy, to provide parental controls and other filters, and to
> comply with relevant laws and regulations, among others.

This list of practices would be much more accurate if it included the
resolver-level DNS practices that we are trying to mitigate using DoH,
including NXDOMAIN synthesis and collection of user browsing history
data.


> Achieving these
> objectives while providing confidentiality and tamper-resistance will
> generally require that network operators shift to one of the available
> encrypted transports for their resolvers and that clients include
> configuration options to select them.

This entirely misses the point, which isn't just to do a lot of encryption
but to provide security for the user. Just having network operators
transition to secure transports while continuing their current practices
does not address the issue.


> Specific initial areas of focus include:
>
> - Resolver discovery
> - Expression of resolver policy
> - Query routing in the presence of resolver choice
> - Best Current Practices for the deployment and operation of encrypted
DNS transport

This seems like it leaves all of the contested issues firmly
in scope. I can't imagine how we're going to get consensus on
best current practices, when we can't even agree on the terms
for resolver selection.

-Ekr

On Wed, Oct 9, 2019 at 12:39 AM Barry Leiba <[e-mail]> wrote:

> Hi, all,
>
> The IESG has worked up a proposal for a possible working group, which
> we're tentatively calling "ABCD", for "Application Behavior
> Considering DNS".  We can discuss the charter proposal here, and
> expect to approve a working-group-forming BoF for Singapore.
>
> I realize that the charter proposal isn't going to please everyone
> (and perhaps will please no one), but it's something that, at a first
> level of review, the IESG accepts and will likely want to move forward
> with.
>
> See the proposal here:
>       https://trac.tools.ietf.org/bof/trac/wiki/WikiStart
>
> I am also going to remove the moderation of this list for now.  Let's
> see how that goes.  Please continue being calm, thoughtful, and
> respectful (and thanks for having done that during the moderation
> period).
>
> Barry
>
> --
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add
>