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

[Suzanne Woolf <[e-mail]>]

> On Oct 9, 2019, at 10:21 AM, Richard Barnes <[e-mail]> wrote:
> 
> There is a bright line here between technology and deployment policy.  The former we have some hope of progressing on, and there are meaty questions around how applications can discover local network capabilities and preferences in a way that is not open to abuse like the mechanisms we have today.  On questions of the latter form, the entire history of this list, and the meeting that preceded it demonstrate, that there is very little hope of consensus.  

I’d be more comfortable if the proposed charter said this, and further if it distinguished between standards-track development of new protocol, extension or fine-tuning of existing protocol, and advice on configuration and deployment.

In DNSOP, and discussion of DNS-based items in other WGs, there’s a distinction between DNS protocol (e.g. defining resolver behavior or, in this case, perhaps resolver discovery), fully backward-compatible and optional extensions and fine-tuning like new EDNS options and RRtypes, and implementation, configuration, or operational advice. 

If we’re talking about protocol to be implemented in software, or operational capability to be configured, for basic deployment— such as standardized resolver discovery, or an EDNS option for interrogating a DOH server for its policy on specific aspects of query handling— it’s possible to come up with  a concise problem description and protocol to solve it. This kind of problem seems like a good candidate for consensus.

Operations-oriented documents can be tricky, but DNSOP has done a number of RFCs where the purpose is to document certain behavior that’s been invented and deployed entirely outside of the standards process. Those documents can be controversial, because if the behavior is seen as harmful by a significant subset of the community, there can be deep divisions in the WG about whether documenting it promotes the harmful behavior, whether the WG should propose improvements to the attributes seen as harmful, and what operators will do with the result— that is, whether the “improved” protocol will be implemented or deployed. But there’s been consensus from time to time that documenting the choices actually available in the field— including how to opt-out or avoid behavior seen as harmful— is an improvement even if the perceived harm can’t be eliminated.

I do share the reservations about a BCP, because a BCP proposes not only documenting the choices, but making claims about “rightness”. Describing tradeoffs between these protocols, the available configuration choices, and how they impact specific aspects of user security seems as if it should be doable, but consensus would be exceptionally difficult around what’s “best”.

> 
> The charter right now has some of both.  If this charter is to go forward, it should be refactored to focus on engineering questions, and avoid policy questions.  In particular, the BCP item needs to be struck.

I think it’s important to be realistic here about what can be accomplished by a group and a process primarily geared towards producing quality technical standards. There are a lot of smart people here and a lot of interesting perspectives on what good policy looks like, but the IETF process may not be the best way to reach consensus on a shared view. We can agree on, for example, a description of how, quantitatively, DNS traffic changes when the resolver is moved from the carrier gateway to 8.8.8.8— but whether the user “should” trust one party more than another is less likely to be agreed on any time soon.


Suzanne

> 
> On Wed, Oct 9, 2019 at 9:50 AM Eric Rescorla <[e-mail] <mailto:[e-mail]>> wrote:
> 
> 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/ <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] <mailto:[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 <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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>
> -- 
> Add mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/add