Subject: [Add] Draft "ABCD" WG Charter

From: Andrew Campling <[email-masked]>
Date: Tue, 10 Dec 2019 22:02:54 +0000

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: +44 (0) 7710 303010 | E: [email-masked]<mailto:[email-masked]>| 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

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 18 Dec 2019 22:25:22 +0000

+1 and ping to question. The longer DoH adoption is left to the industry to handle without IETF helping standardize, the greater the risk to interoperability of well-intended DNS ecosystem participants.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Andrew Campling <[email-masked]>
Sent: Tuesday, December 10, 2019 2:02 PM
To: [email-masked] <[email-masked]>
Subject: [EXTERNAL] [Add] Draft "ABCD" WG Charter

Message to ADs

Andrew

Regards

---

From: Rob Sayre <[email-masked]>
Date: Wed, 18 Dec 2019 14:34:49 -0800

On Wed, Dec 18, 2019 at 2:25 PM Tommy Jensen <Jensen.Thomas=
[email-masked]> wrote:

> +1 and ping to question. The longer DoH adoption is left to the industry
> to handle without IETF helping standardize, the greater the risk to
> interoperability of well-intended DNS ecosystem participants.
> https://www.ietf.org/mailman/listinfo/add

Are there any interoperability problems that are not also present in
classic DNS? The DoH draft seems to be pretty successful so far.

To refresh, here's the last few comments from Barry and Alissa at the last
BoF:
https://youtu.be/J6315Ax51RE?t=5359

thanks,
Rob

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 19 Dec 2019 09:30:57 -0500

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 <[email-masked]> wrote:
> 
> Message to ADs
> Director | 419 Consulting Ltd | Tel: +44 (0) 7710 303010 | E: [email-masked] <mailto:[email-masked]>| t: @Andrew_Campling
>  
> <Picture (Device Independent Bitmap) 1.jpg>
>  
>  
>  
> -- 
> Add mailing list
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>

---

From: Tommy Pauly <[email-masked]>
Date: Thu, 19 Dec 2019 16:13:58 -0800

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

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;

- allow network providers to communicate DNS policy to clients,
including information about locally-accessible names;

- inform clients about how to select appropriate encrypted and
unencrypted resolvers for DNS queries in various network environments
and use cases.

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.

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.

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.

> On Dec 19, 2019, at 6:30 AM, Alissa Cooper <[email-masked]> wrote:
> 
>> On Dec 10, 2019, at 5:02 PM, Andrew Campling <[email-masked] <mailto:[email-masked]>> wrote:
>> 
>> Message to ADs
> [email-masked]

---

From: Tommy Jensen <[email-masked]>
Date: Fri, 20 Dec 2019 01:02:18 +0000

Thanks, Alissa; you weren't joking by "shortly" I see. Thanks for posting, Tommy.

I support adoption of this charter. Discoverability and policy communication have repeatedly come up on this list as items we can widely agree deserve focus, so that makes sense as the highlight of the charter. The scope is narrower, leaving existing scopes to existing WGs, and openly calls out the inclusion of the different scenarios which have historically split this list without giving any camp a clear priority over the other.

+1 for reusing the mailing list acronym.

Thanks,
Tommy
________________________________
From: Add <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Sent: Thursday, December 19, 2019 4:13 PM
To: [email-masked] <[email-masked]>
Cc: Andrew Campling <[email-masked]>; Alissa Cooper <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Draft "ABCD" WG Charter

Hello ADD,

Best,
Tommy

On Dec 19, 2019, at 6:30 AM, Alissa Cooper <[email-masked]<mailto:[email-masked]>> wrote:

Best,
Alissa

On Dec 10, 2019, at 5:02 PM, Andrew Campling <[email-masked]<mailto:[email-masked]>> wrote:

Message to ADs

Andrew

Regards

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fadd&data=02%7C01%7CJensen.Thomas%40microsoft.com%7C36830decf0fe4aaff29108d784e18cdf%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637123976585740354&sdata=ksc9AFZSde8d0dlPvHmiNSmOEgvNcv5fbEC3QWecLpo%3D&reserved=0>

--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

---

From: Stephen Farrell <[email-masked]>
Date: Fri, 20 Dec 2019 12:42:29 +0000

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/

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!
> 
> Best, Tommy
> Adaptive DNS Discovery (ADD) ==================================== 
> 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.
> 
> 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;-)

> 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.

> 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?

> 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.

> 
> The Adaptive DNS Discovery (ADD) working group will define mechanisms
> and protocols to:
> 

Why call out DoH like that? If there's no reason then I'd
leave it out.

> 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?)

> 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.

> networks, enterprise networks, captive networks, and school 

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.

> 
> 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 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.
> 
> (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.

Cheers,
S.

>> Best, Alissa
>>> On Dec 10, 2019, at 5:02 PM, Andrew Campling 
>>> <[email-masked] 
>>> <mailto:[email-masked]>> 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
>>> 
>>> Director | 419 Consulting Ltd | Tel: +44 (0) 7710 303010 | E: 
>>> [email-masked] <mailto:[email-masked]>| 
>>> 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
>>> 
>>> -- Add mailing list [email-masked] <mailto:[email-masked]> 
>>> <https://www.ietf.org/mailman/listinfo/add>
>> -- Add mailing list [email-masked]

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 23 Dec 2019 08:30:39 -0800

Hi Stephen,

Thanks for the comments! Responses inline.

Best,
Tommy

> On Dec 20, 2019, at 4:42 AM, Stephen Farrell <[email-masked]> wrote:
> 
> 
> Hiya,
> 
> https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/ <https://datatracker.ietf.org/doc/draft-pauly-dprive-adaptive-dns-privacy/>
> 

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".

> I don't think the decisions vary. It's the right answers

Indeed. A good fix.

> 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.

> 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.

> Why call out DoH like that? If there's no reason then I'd

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).

> make sense. (But would that not be more of a dnsop spec I

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)

> 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.

> 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.

> 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. =)
> that I think experimental is the right category and sends

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 <[email-masked] <mailto:[email-masked]>> 
>>> wrote:
>>> 
>>>> <[email-masked] <mailto:[email-masked]> 
>>>> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>>> 
>>>> [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>| 
>>>> t: @Andrew_Campling
>>>> 
>>>> -- Add mailing list [email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>> 
>>>> <https://www.ietf.org/mailman/listinfo/add <https://www.ietf.org/mailman/listinfo/add>>
> <0x5AB2FAF17B172BEA.asc>-- 
> Add mailing list

---

From: Rob Sayre <[email-masked]>
Date: Mon, 23 Dec 2019 11:34:19 -0800

> While we can certainly leave "school networks" off of the charter text,

Definitely. Perhaps "captive networks" is the only description needed.

> that looks like encrypted DNS might need to be considered.

What would graceful behavior be? For example, my Android phone connects to
Google's VPN on every network.

As you are no doubt aware, on some devices, it's possible to issue DNS
queries over cellular and conduct other traffic on Wifi/Ethernet.

thanks,
Rob

---

From: Tommy Pauly <[email-masked]>
Date: Mon, 23 Dec 2019 11:59:05 -0800

> On Dec 23, 2019, at 11:34 AM, Rob Sayre <[email-masked]> wrote:
> 
> On Mon, Dec 23, 2019 at 8:31 AM Tommy Pauly <tpauly=[email-masked] <mailto:[email-masked]>> wrote:

I do think enterprise networks are also important, in that they have a very legitimate use case to define the resolution
of internal names (like a VPN does) without necessarily having the explicit indication of configuration that a VPN provides today.

> What would graceful behavior be? For example, my Android phone connects to Google's VPN on every network.
> 
> As you are no doubt aware, on some devices, it's possible to issue DNS queries over cellular and conduct other traffic on Wifi/Ethernet.

Certainly! To take a note from the previous Multiple Interfaces group, a device needs to deal with any number of
Provisioning Domains (https://tools.ietf.org/html/rfc7556) that may be usable simultaneously.

We often use cellular at the same time as Wi-Fi for select traffic, and one or more VPNs on top of that, etc. Keeping the
DNS answers straight is critical.

What I was referring to by "graceful behavior" here was handling the case in which connections to DNS servers fail. Like with
captive networks, the client device needs to decide if it should:
- Drop the network association or make it a non-default route, since connectivity seems to be "broken";
- or, fall back to using unencrypted DNS, presumably letting the user know. This is potentially like how we can currently
let a user stay on a captive network/walled-garden without connectivity if they want.

Thanks,
Tommy

---

From: Rob Sayre <[email-masked]>
Date: Mon, 23 Dec 2019 12:44:56 -0800

On Mon, Dec 23, 2019 at 11:59 AM Tommy Pauly <[email-masked]> wrote:

> I do think enterprise networks are also important, in that they have a
> very legitimate use case to define the resolution
> of internal names (like a VPN does) without necessarily having the
> explicit indication of configuration that a VPN provides today.
>

Sure, but they're a subset of captive networks. For example, consider the
archetypal captive network, airplane wifi. They tend to let you resolve
airline information and locally-served videos, but nothing else.

> We often use cellular at the same time as Wi-Fi for select traffic, and
> one or more VPNs on top of that, etc. Keeping the

All true, but this is not a security measure. If you let devices you don't
manage onto your network, they can conduct DNS queries using other links
and methods.

I'm struggling to see why the proposed WG should view DNS traffic from
non-managed devices as a security concern that can be addressed by an IETF
protocol. I do get that there was an equilibrium up until recently, but
that seems to be going away, and is probably already gone in the case of
malicious actors (example: some malware seems to be conducting DNS via
Instagram comments).

Since the security angle seems to be moot, the remaining issues seem to
center on tracking, where there is much less consensus.

>
> What I was referring to by "graceful behavior" here was handling the case
> in which connections to DNS servers fail. Like with
> - or, fall back to using unencrypted DNS, presumably letting the user
> know. This is potentially like how we can currently

Right, but there is another concern here around "fall back". Even if the
DHCP-provided DNS server supports DoH/DoT, users do not tend to actively
select it.

For example, does it really make sense for my computer to trust
"10.0.11.14" as a DNS server, whether the traffic is served via TLS or not?
That was the DNS server provided by the last hotel I stayed at, and I think
most operating systems and applications would use it. To me, that "fall
back" concern you mention involves resolver selection in addition to
encryption, and I am not sure work on resolver selection will be productive.

thanks,
Rob