Re: [Add] Draft "ABCD" WG Charter

[Tommy Pauly <[e-mail]>]

Hi Stephen,

Thanks for the comments! Responses inline.

Best,
Tommy

> On Dec 20, 2019, at 4:42 AM, Stephen Farrell <[e-mail]> wrote:
> 
> 
> Hiya,
> 
> I'm supportive of progressing [1], but I'm not sure if a
> WG as envisaged by this is the right vehicle for doing
> that. (It may be, I'm honestly not sure.)
> 
> If this text were to be the starting point for a WG
> charter then I have some comments below. I think some of
> those would really need to be fixed or a WG could end up
> ratholing in a couple of ways.
> 
> Cheers,
> S.
> 
> [1]
> https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/ <https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/>
> 
> On 20/12/2019 00:13, Tommy Pauly wrote:
>> Hello ADD,
>> 
>> I wanted to share a charter proposal for the ADD/ABCD work to get 
>> this discussion underway. Based on the discussion at the BoF in 
>> Singapore, there was a desire to have more clearly scoped 
>> deliverables. We had presented our draft on Adaptive DNS Privacy, 
>> which described a few mechanisms that help clients discover and 
>> interact with local networks. Several people indicated at the mic 
>> that they would be interested in seeing a version of a charter based
>> around the mechanisms we had presented.
>> 
>> Note that this is just one direction we can take, and I expect that 
>> the authors of the original charter will share another revision soon
>> as well. Hopefully, this provides a useful input for the
>> discussion!
>> 
>> Any comments or thoughts are welcome.
>> 
>> Best, Tommy
>> 
>> 
>> 
>> Adaptive DNS Discovery (ADD) ==================================== 
>> Proposed Working Group Charter
>> 
>> Sending DNS messages over encrypted transports, as defined in DNS 
>> over TLS (DoT) [RFC 7858] and DNS over HTTPS (DoH) [RFC 8484], 
>> provides benefits to the security and privacy of DNS data. Clients, 
>> such as applications and host operating systems, have started 
>> adopting these protocols to provide these user benefits. Depending on
>> the situation and use case, this can involve selecting a DNS server
>> other than one provisioned by a local network.
>> 
>> Clients that want to adopt encrypted DNS protocols need to determine 
>> which DNS servers support encrypted transports,
> 
> That bit seems wrong in two ways. The first is easy;-)
> 
> - DNS servers can be authoritatives, I don't think you
> want to include that discovery problem in scope as it's
> being tackled in dprive already. (The same issue crops up
> elsewhere, so an editing pass to clarify that you're only
> talking about stub/recursive interactions would be good,
> assuming that's the case.)
> 
> - A client does not "need to determine" the set of all DNS
> recursives on the Internet that support DoH/DoT etc. I
> think getting this bit right is tricky though, as it goes
> to the heart of what discovery problem the putative WG is
> to address. (I was trying to come up with suggested text
> that's better, but none of the options I came up with
> really worked, sorry;-)

Right, I agree with your clarifications here. Clients certainly don't need to discover *all*
resolvers that support encrypted transports. Rather, they need to discover which among
the resolvers they normally deal with support encryption; as well as any other external
resolvers that may be appropriate if the client wants to use an encrypted transport.

In some ways, it's similar to marking ALT-SVC for moving TLS/TCP connections to QUIC:
there needs to be a way to indicate, "this resolver may not support the protocol you want,
but you can get that service at this other resolver".

> 
>> and which server to use in which context if multiple servers are 
>> available. These decisions can vary based on the network
>> environment, and also based on the content and purpose of the client
>> queries.
> 
> I don't think the decisions vary. It's the right answers
> that vary.

Indeed. A good fix.

> 
> 
>> For instance, the use of DNS servers associated with a particular 
>> content or domain when accessing that content or domain may be 
>> beneficial from a privacy perspective.
>> 
>> Network operators that start offering DNS encryption on their
>> servers need a way to indicate this support to clients.
> 
> Why say "start" there? Do you envisage something different
> happening when DoT/DoH is first turned on?

No, we can remove "start". That was just indicating that this is a relatively
new development without a lot of deployment experience yet.

> 
>> Beyond support for encrypted DNS, local networks may also have
>> policy about the use of DNS to non-local DNS servers. Communicating
>> such network policy to clients would allow clients to make more
>> informed decisions about which DNS servers to use.
> 
> "Communicating such network policy" is such a potential can
> of worms (with a history of failure!) that I think it'd be
> way better to leave this out *or* to be much more specific
> about how this is limited and what it's for.

I think we can clarify this. I can imagine something similar to how we
are working on specifying the captive portal behavior, which is a similarly
complicated effort, but one where we can hopefully add value.

> 
>> 
>> The Adaptive DNS Discovery (ADD) working group will define mechanisms
>> and protocols to:
>> 
>> - allow clients to discover encrypted DNS resolvers, such as DoH 
>> servers, that are available publicly or on local networks;
> 
> Why call out DoH like that? If there's no reason then I'd
> leave it out.

I called it out here to ensure that any mechanism was sufficient to support discovering
the DoH URI (which requires a bit more than what you need for DoT, etc).

> 
>> 
>> - allow network providers to communicate DNS policy to clients, 
>> including information about locally-accessible names;
> 
> See above - "communicate DNS policy" is a potential giant
> rathole. If it were limited to describing the scope of
> locally-resolved names then that might well be useful and
> make sense. (But would that not be more of a dnsop spec I
> wonder?)

Agreed that clarifying the scope here would help. At first pass, I would see this include:
- Locally managed names/zones
- If this network allows external access at all (for captive/walled-garden networks)

> 
>> 
>> - inform clients about how to select appropriate encrypted and 
>> unencrypted resolvers for DNS queries in various network
>> environments and use cases.
> 
> I don't know what that means. If the client has code for
> picking between recursives then it knows "how to select"
> already. Unless you're sending down JS or something then
> a server can provide input only.

I think this ought to be more about specifying the client behavior algorithm for managing
its split-DNS environment of local and external resolvers.

> 
>> 
>> The mechanisms defined by this working group will consider several 
>> deployment scenarios, including public networks, home and mobile 
>> networks, enterprise networks, captive networks, and school 
>> networks.
> 
> I don't think it's our business to develop protocols to
> support the censorship common in some countries' school
> (or prison) networks. I do understand that's a real problem
> but I don't think we have consensus that it's the IETF's
> problem. I'd say best to just omit that.

While we can certainly leave "school networks" off of the charter text,
and we don't need to explicitly provide mechanisms for that case, defining
graceful behavior for networks that may aggressively block any connections
that looks like encrypted DNS might need to be considered.

> 
>> 
>> Any mechanisms that specify interactions between clients and servers
>> must provide the security properties expected of IETF protocols, 
>> e.g., confidentiality protection, integrity protection, and 
>> authentication with strong work factor.
> 
> So no DHCP then?
> 
> I'm also unsure what you mean by confidentiality here - to
> do discovery we have to expose information or we end up in
> a loop. That's probably just a wording thing though?

This was mainly lifted from some boiler-plate security text for charters, so happy to
see it modified. =)
> 
>> 
>> This working group will coordinate with dnsop, doh, and dprive for 
>> any changes required in DNS protocols. It will also work with capport
>> to ensure that solutions are applicable to captive networks.
>> 
>> The starting point for the group's work is Adaptive DNS 
>> (draft-pauly-dprive-adaptive-dns-privacy), subject to the working 
>> group's design choices.
> 
> I do like that draft. But I think it's complex enough that
> it ought be progressed as an experimental RFC. That's not a
> huge deal but I do think it's appropriate in this case.
> There are so many moving parts that may change during the
> development of the RFC, and after people start deploying,
> that I think experimental is the right category and sends
> the right signal.

Sure, that's fine! With regards to how it fits into these efforts, I can certainly
see it being broken up into multiple documents with individual mechanisms
that progress as we have experience deploying things.
> 
> Cheers,
> S.
> 
>> 
>> 
>>> On Dec 19, 2019, at 6:30 AM, Alissa Cooper <[e-mail] <mailto:[e-mail]>> 
>>> wrote:
>>> 
>>> There are charter-drafting efforts underway so I suspect updates 
>>> will be sent to the list shortly.
>>> 
>>> Best, Alissa
>>> 
>>> 
>>>> On Dec 10, 2019, at 5:02 PM, Andrew Campling 
>>>> <[e-mail] <mailto:[e-mail]> 
>>>> <mailto:[e-mail] <mailto:[e-mail]>>> wrote:
>>>> 
>>>> Message to ADs Any update on the draft WG Charter?  We seemed to
>>>> get to consensus in the BoF that a WG was needed, just timed out
>>>> on getting to agreement on the content.  It would be good to get
>>>> the draft charter out to the list for comment so this can be 
>>>> finalised and the group up and running well in advance of IETF 
>>>> 107 if possible.
>>>> 
>>>> Andrew
>>>> 
>>>> 
>>>> Regards
>>>> 
>>>> Andrew Campling  MBA  MSc  DipM  FRSA  MCIM  MIoD  Liveryman 
>>>> Director | 419 Consulting Ltd | Tel: [phone] | E: 
>>>> [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>>| 
>>>> t: @Andrew_Campling
>>>> 
>>>> This email contains information from 419 Consulting Ltd that 
>>>> might be privileged or confidential. And it's only meant for the
>>>> person above. If that's not you, we're sorry - we must have sent
>>>> it to you by mistake. Please email us to let us know, and don't
>>>> copy or forward it to anyone else. Thanks.
>>>> 
>>>> We monitor our email systems and may record all our emails. 419 
>>>> Consulting Ltd Registered in England: No 11944258
>>>> 
>>>> <Picture (Device Independent Bitmap) 1.jpg>
>>>> 
>>>> 
>>>> 
>>>> -- Add mailing list [e-mail] <mailto:[e-mail]> <mailto:[e-mail] <mailto:[e-mail]>> 
>>>> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add> 
>>>> <https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>>
>>> -- Add mailing list [e-mail] <mailto:[e-mail]> 
>>> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>
>> 
>> 
>> 
> <0x5AB2FAF17B172BEA.asc>-- 
> Add mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>