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

[Richard Barnes <[e-mail]>]

I think EKR is on the right track here.

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.

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.

--RLB

On Wed, Oct 9, 2019 at 9:50 AM Eric Rescorla <[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/
> )
> 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
>>
>