Subject: Re: [Add] A proposed charter for ABCD

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Thu, 9 Jan 2020 22:56:25 +0000

On 1/9/20, 12:20 PM, "Add on behalf of Ted Lemon" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

On Jan 9, 2020, at 11:43 AM, Alissa Cooper <[email-masked]<mailto:[email-masked]>> wrote:
I suspect a rev of the charter Tommy posted in December [1] to reflect comments in that thread would be close enough to start the community-wide feedback step of the chartering process, given the support expressed for it thus far.

[1] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w<https://urldefense.com/v3/__https:/mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w__;!!PIZeeW5wscynRQ!5Xtwq7GDLoe3CrUibt5gPJJpk-KRe2hesZ2NretDWvA3mD6Yas5OMgADAbFNJfGQ$>

I agree with this in a general sense, although figuring out how to update Tommy’s proposal based on the subsequent discussion might be challenging because there’s been so much of it.

I do not think Glenn Dean’s proposal is a good place to start.  It would however be useful for Glenn to say what he would want changed in Tommy’s version of the charter.

[GD] As I said in my other notes – Tommy’s version is very similar in its goals which is a very good sign.  The main difference is how much and what you front load the WG with constraints on where they start and how they have to proceed.

The areas that I would change would be to remove a few things:

  1.  I would remove the following since I think the getting into informing clients of what is appropriate is both a can of worms, and gets into the realm of telling the clients what to choose versus the clients pulling the information they want and then making their choice based on whatever logic they have in the client.

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

2.    Remove (below) the Adaptive DNS draft starting point because as it currently is Adaptive DNS goes beyond D&S and gets into interesting areas of resolver behavior including the MUST requirement that DoH servers support ubiquitous DNS.   That’s more than D&S as I say is interesting but it’s far more than the WG should try to take on if it wants to be able to reasonably deliver output.   BTW – I’m not saying don’t discuss such things. I am simply saying such things would better be done in another WG.

             The starting point for the group's work is Adaptive DNS (draft-pauly-dprive-adaptive-dns-privacy), subject tothe working group's design choices.

  1.  I would also do an edit to make sure it is not specific to DoH and DoT and make it about any DNS. The current rev. mentions unencrypted DNS in some places and focuses on DoH in others. Both Encrypted DNS and even traditional DNS/53 since if the group were to produce a better way of discovering and selecting DNS resolvers there isn’t any reason to limit its use to encrypted DNS. Network environments like enterprises that may choose to use DNS/53 could benefit from it.

  1.  I continue to advocate for changing the name to not be ADD. Too much baggage comes with it.  I continue to propose the simpler DNS Discovery and Selection or DNS-DS

On 1/9/20, 12:20 PM, "Add on behalf of Ted Lemon" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

The problem with Glenn’s proposal is that it largely ignores what has been discussed thus far, and leaves things wide open rather than tightly scoped, which has caused problems in the past.  A DHCP option to configure DoH servers would be in-scope for Glenn’s charter, for example, and could be done without any discussion about how to establish or validate trust, which I think would be an unfortunate outcome because there would be no point in implementing it.

[GD] While it would be in scope, it would be subject to the WG participants discussing it and having to come to consensus on it.     Any WG’s mission is not to force any particular outcome – it’s to bring the parties together and to work through what is brought to the table in the form of drafts and comments and to hopefully develop consensus around harmonized proposals.   Any such proposal would also need to deal with both security and privacy considerations in order to move forward.

I’m not saying I advocate for such things, or that anyone is going to put forth a draft proposing doing it with basic  existing DHCP, but I wouldn’t be surprised if such things do show up in deployments in the wild.    There may be value in having someone capture the issues around doing it so that there is a thread or repository of knowledge that people can refer to when considering doing such a thing.

Finally, my intent was not to ignore what has been discussed thus far, or have them disappear.  I figured the existing ideas that have had some discussion on the ADD list would be seeds for more discussion.  What’s lacking to pull those together in a useful way is an actual WG and drafts in that WG to manage those comments.

Here then is what those edits would look like:

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.

Discovering and selecting DNS Resolvers by DNS clients is then an essential

step in clients selecting the resolver to use in this more diverse environment

where regardless of if the choice is an encrypted DNS resolver supporting

DoH or DoT or legacy unencrypted DNS/53 recursive resolution.

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;

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.

-glenn deen

---

From: Mirja Kuehlewind <[email-masked]>
Date: Fri, 10 Jan 2020 11:35:29 +0100

Hi Glen,

See a few small comments inline 

> On 9. Jan 2020, at 23:56, Deen, Glenn (NBCUniversal) <[email-masked]> wrote:
> 
[snip]
> 	• I would remove the following since I think the getting into informing clients of what is appropriate is both a can of worms, and gets into the realm of telling the clients what to choose versus the clients pulling the information they want and then making their choice based on whatever logic they have in the client.
>  

So this is the only part in the proposed charter that actually talk about selection. If you want to work on discovery AND selection the charter should say that. Maybe this point as currently phrased a bit too broad and we can be more concrete here? 

I would also be okay to say for now that the group will work on discovery mechanism first and advance selection mechanisms need rechartering. However, as I said in a previous mail, I don’t think we can design the discovery mechanisms correctly if we don’t have at least a few simple selection policies in mind that could be used.

>              The starting point for the group's work is Adaptive DNS (draft-pauly-dprive-adaptive-dns-privacy), subject tothe working group's design choices.

See my other mail I’ve just sent.

>  
> 	• I would also do an edit to make sure it is not specific to DoH and DoT and make it about any DNS. The current rev. mentions unencrypted DNS in some places and focuses on DoH in others. Both Encrypted DNS and even traditional DNS/53 since if the group were to produce a better way of discovering and selecting DNS resolvers there isn’t any reason to limit its use to encrypted DNS. Network environments like enterprises that may choose to use DNS/53 could benefit from it.    
>  
> 	• I continue to advocate for changing the name to not be ADD. Too much baggage comes with it.  I continue to propose the simpler DNS Discovery and Selection or DNS-DS

DNS-DS might be confusing with RFC6763 (DNS-Based Service Discovery).

Mirja

---

From: "Ian Maddison" <[email-masked]>
Date: Fri, 10 Jan 2020 15:53:38 +0100

> DNS-DS might be confusing with RFC6763 (DNS-Based Service Discovery).

Yeah I thought that too. 

How about DNS Pick n Choose

---

From: Ben Schwartz <[email-masked]>
Date: Tue, 14 Jan 2020 16:43:39 -0500

Thanks for attempting a consensus charter, Glenn.  Some comments inline.

On Thu, Jan 9, 2020 at 5:56 PM Deen, Glenn (NBCUniversal) <
[email-masked]> wrote:
...
> Proposed Working Group Charter
...
> would allow clients to make more informed decisions about which DNS

I feel strongly that we should avoid "policy" in the WG scope text.  We
appear to lack a shared understanding of what this word means, and it is
the focus of much conflict here.  Including it here seems like a recipe for
confrontation within the working group.  I also don't think it's necessary
for almost any of the goals mentioned on this list: we can rephrase in a
way that is both clearer and more broadly acceptable.

In this case, I would suggest: "... servers need a way to indicate this
support to clients.  Clients may also be able to make better decisions
about which DNS servers to use if they can learn more about the resolution
behaviors of each server.".

> The Adaptive DNS Discovery (ADD) working group will define mechanisms and
...
> including information about locally-accessible names;

In this case, I would rephrase as "... communicate information about
resolver behavior to clients, including ...".

...
> and authentication with strong work factor.

This appears to rule out opportunistic upgrade to DoH, as well as the
entire RESINFO framework adopted by DNSOP.  Personally, I don't think "the
security properties expected of IETF protocols" are compatible with most of
the use cases we've discussed, including the ones mentioned in this charter
text.  I think we would be better off flipping this to explicitly focus on
opportunistic protocols, and promise to document appropriate guardrails
against improper reliance on security properties that are not provided.

While opportunistic security is not to be relied on for crucial security
properties, I think opportunistic privacy (against a passive adversary)
is valuable and worth including in the working group's scope.  Also,
opportunistic upgrade would give clients a clear indication that they are
speaking directly to a modern resolver, allowing them to rely on modern DNS
features.  In the absence of such a signal, clients cannot rely on any DNS
features beyond basic A/AAAA queries, due to the lingering deployment of
buggy resolvers, forwarders, and middleboxes.  I know that this has been a
major factor in popular clients' decisions not to make use of EDNS, DNSSEC,
and other modern DNS features.

---

From: "Deen, Glenn (NBCUniversal)" <[email-masked]>
Date: Tue, 14 Jan 2020 22:43:28 +0000

Ben

I fully agree on your point about. In the update Tommy just posted we got rid of the policy word all together.

To your point on opportunistic, I believe the updated proposal would permit that.

Glenn

On Jan 14, 2020, at 1:44 PM, Ben Schwartz <[email-masked]> wrote:

On Thu, Jan 9, 2020 at 5:56 PM Deen, Glenn (NBCUniversal) <[email-masked]<mailto:[email-masked]>> wrote:
...
...
> would allow clients to make more informed decisions about which DNS

I feel strongly that we should avoid "policy" in the WG scope text.  We appear to lack a shared understanding of what this word means, and it is the focus of much conflict here.  Including it here seems like a recipe for confrontation within the working group.  I also don't think it's necessary for almost any of the goals mentioned on this list: we can rephrase in a way that is both clearer and more broadly acceptable.

In this case, I would suggest: "... servers need a way to indicate this support to clients.  Clients may also be able to make better decisions about which DNS servers to use if they can learn more about the resolution behaviors of each server.".

...
> including information about locally-accessible names;

In this case, I would rephrase as "... communicate information about resolver behavior to clients, including ...".

...
> and authentication with strong work factor.

This appears to rule out opportunistic upgrade to DoH, as well as the entire RESINFO framework adopted by DNSOP.  Personally, I don't think "the security properties expected of IETF protocols" are compatible with most of the use cases we've discussed, including the ones mentioned in this charter text.  I think we would be better off flipping this to explicitly focus on opportunistic protocols, and promise to document appropriate guardrails against improper reliance on security properties that are not provided.

While opportunistic security is not to be relied on for crucial security properties, I think opportunistic privacy (against a passive adversary) is valuable and worth including in the working group's scope.  Also, opportunistic upgrade would give clients a clear indication that they are speaking directly to a modern resolver, allowing them to rely on modern DNS features.  In the absence of such a signal, clients cannot rely on any DNS features beyond basic A/AAAA queries, due to the lingering deployment of buggy resolvers, forwarders, and middleboxes.  I know that this has been a major factor in popular clients' decisions not to make use of EDNS, DNSSEC, and other modern DNS features.

---

From: Tommy Pauly <[email-masked]>
Date: Tue, 14 Jan 2020 14:45:53 -0800

Hi Ben,

As a note, Glenn and I worked on a revision of this today that I have sent out to the list that should cover most of your comments.

Anything specifically naming "policy" has been removed throughout the charter proposal. We did toss around the idea of "resolver behavior" but ended up being a bit more general in referring to information about the resolver, that can be used in resolver selection. The main goal here is to provide a communication mechanism in the IETF spec for properties that describe what a resolver will serve, the most concrete example of which is information about serving split DNS names. This communication mechanism could be used for "policy" or "behavior" information, but that would certainly be out of scope for this working group.

With regards to the text for "security properties", this mainly came from boilerplate security charter text. I don't read that as necessarily ruling out opportunistic use of encryption as a strategy, but any communication of explicit information between two parties (servers and clients in this example) should be specified to be secure. I would argue that just trying DoH to a given address does give you the security properties of HTTPS when you use that; but that's also not any new protocol mechanism.

Best,
Tommy

> On Jan 14, 2020, at 1:43 PM, Ben Schwartz <bemasc=[email-masked]> wrote:
> 
> On Thu, Jan 9, 2020 at 5:56 PM Deen, Glenn (NBCUniversal) <[email-masked] <mailto:[email-masked]>> wrote:
> ... 
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 14 Jan 2020 23:23:15 +0000

Hiya,

On 14/01/2020 22:45, Tommy Pauly wrote:
> 
> With regards to the text for "security properties", this mainly came
> from boilerplate security charter text.

Better deleted IMO. But clarity on whether or not
opportunistic approaches are in scope is needed I
reckon (as part of the charter).

> I don't read that as
> necessarily ruling out opportunistic use of encryption as a strategy,
> but any communication of explicit information between two parties
> (servers and clients in this example) should be specified to be
> secure. I would argue that just trying DoH to a given address does
> give you the security properties of HTTPS when you use that; but
> that's also not any new protocol mechanism.

FWIW, I don't agree with the above.

I do think there's value in opportunistic approaches so
long as there's some kind of credible longer term story
as to how we get to better than opportunistic. I read
your charter text as strongly discouraging that.

In addition, if any step in the process lacks strong
identification and authentication, then the overall is
back to opportunistic. In particular, if the client
does not start out already knowing a public key and a
name for a resolver (or maybe just a public key if
something "above" a resolver like a special purpose
PKI were to exist) that the client "likes" then ISTM
that HTTPS is no better than than opportunistic
anyway.

And since the status-quo ante is mostly DHCP, I think
we'd be silly to ignore the potential for opportunistic
improvement *if* we think there's a path from that to
better eventually. (*)

Cheers,
S.

(*) To try give an example of what I mean: if my laptop
has successfully used resolver foo 1000 times in the last
year without any hiccups, and I walk into a coffee shop
that tells me via DHCP that I can use foo, then that's
fine and dandy. That's not quite TOFU, maybe more like
trust on thousandth use or TOTU perhaps?

---

From: Brian Dickson <[email-masked]>
Date: Tue, 14 Jan 2020 16:45:10 -0800

> trust on thousandth use or TOTU perhaps?
I think we are likely converging on some common, good ideas.

There was a reference to work in the INT area, on PvD, which I think can
dovetail with the things we're thinking of here.
(PvD is basically "provisioning domains", which by my reading really means
"domains within which provisioning occurs" rather than "provisioning DNS".)

Here's how I think the two could interact in a way that gets us where we
want to be:
- The PvD is a "context" within which any bootstrapping or recall occurs,
for going from supplied thing (e.g. DHCP address) to identified,
authenticated, trusted resolver over a privacy-preserving channel.
- If a given PvD context is new, TOFU via a well-known name, which asserts
its own trust anchor over a signed zone (of the well-known name).
- The signed zone contains a reference to a unique name (globally unique,
but locally scoped, i.e. works without requiring any global DNS delegation,
works in non-unique private address space, works without PKI)
- The signed zone also has a trust anchor (DNSKEY) for the unique name, so
all other information can be obtained from the signed zone under that
unique name.
- If a given PvD context is not new, the trust anchor for the well-known
name has been saved
- If the well-known name points at the previously used unique name, the
only reason the trust anchor of the unique name might have changed is if
the key was rolled, which is a valid possibility. Use the copy under the
well-known name if the trust anchor has changed.
- If the trust anchor hasn't changed, it is moot as to which identical copy
is used (from well-known name or from unique name)
- If the trust anchor for the well-known name doesn't match, reject it,
ignore the well-known name entirely, and jump to the previously
bootstrapped secure unique name (using the stored trust anchor of the
unique name).

It still starts with TOFU, but only if the client doesn't have anything
better configured, and only if it is the first time it has encountered this
environment.

If the name of the resolver is resolvable from the global public DNS
context (has a real name of its own), there is no need to rely on anything
other than the name learned via the TOFU step. The DNSSEC elements can
chain from the root trust anchor.

If the name of the resolver is not resolvable from the global public DNS,
that means that PKI won't work, so certificates need to be issued and
validated via some other means (necessarily), which suggests DANE TLSA
record(s) learned in the securely bootstrapped uniquely named resolver's
own zone.

Something better than TOFU can be worked out in the longer term, but that
doesn't need to be (IMHO) done within DNS WGs, so long as the data given to
clients is compatible with the secure bootstrap process (e.g. DNSSEC trust
anchor, and possibly the resolver name.)

Brian

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 15 Jan 2020 00:55:58 +0000

Hiya,

> - If a given PvD context is not new, the trust anchor for the well-known

"Not new" could be satisfied by dropping WiFi and then
starting over in milliseconds. I'm not clear that that'd
be ok here. So it may or may not be the case that we're
converging. A WG that is chartered to analyse opportunistic
situations could figure that out I guess.

S.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 14 Jan 2020 20:27:02 -0500

On Jan 14, 2020, at 7:45 PM, Brian Dickson <[email-masked]> wrote:
> 
> PvD is basically "provisioning domains", which by my reading really means "domains within which provisioning occurs" rather than "provisioning DNS".

No need to speculate—the term is defined in RFC 7556—Multiple Provisioning Domain Architecture.

https://tools.ietf.org/html/rfc7556

---

From: "Winfield, Alister" <[email-masked]>
Date: Wed, 15 Jan 2020 16:29:28 +0000

I see this revision as good progress and support this charter proposal.

Alister Winfield.

From: Add <[email-masked]> on behalf of Tommy Pauly <tpauly=[email-masked]>
Date: Tuesday, 14 January 2020 at 22:46
To: Ben Schwartz <bemasc=[email-masked]>
Cc: "Deen, Glenn (NBC Universal - Guest)" <[email-masked]>, Alissa Cooper <[email-masked]>, Ted Lemon <[email-masked]>, ADD Mailing list <[email-masked]>, ""Mirja Kühlewind (IETF)"" <[email-masked]>, Stephen Farrell <[email-masked]>
Subject: [EXTERNAL] Re: [Add] A proposed charter for ABCD

Hi Ben,

Best,
Tommy

On Jan 14, 2020, at 1:43 PM, Ben Schwartz <bemasc=[email-masked]<mailto:bemasc=[email-masked]>> wrote:

...

...
> including information about locally-accessible names;

In this case, I would rephrase as "... communicate information about resolver behavior to clients, including ....".

...

While opportunistic security is not to be relied on for crucial security properties, I think opportunistic privacy (against a passive adversary) is valuable and worth including in the working group's scope.  Also, opportunistic upgrade would give clients a clear indication that they are speaking directly to a modern resolver, allowing them to rely on modern DNS features.  In the absence of such a signal, clients cannot rely on any DNS features beyond basic A/AAAA queries, due to the lingering deployment of buggy resolvers, forwarders, and middleboxes.  I know that this has been a major factor in popular clients' decisions not to make use of EDNS, DNSSEC, and other modern DNS features.
--
Add mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/add

--------------------------------------------------------------------
This email is from an external source. Please do not open attachments or click links from an unknown or suspicious origin. Phishing attempts can be reported by sending them to [email-masked] as attachments. Thank you
--------------------------------------------------------------------

Information in this email including any attachments may be privileged, confidential and is intended exclusively for the addressee. The views expressed may not be official policy, but the personal views of the originator. If you have received it in error, please notify the sender by return e-mail and delete it from your system. You should not reproduce, distribute, store, retransmit, use or disclose its contents to anyone. Please note we reserve the right to monitor all e-mail communication through our internal and external networks. SKY and the SKY marks are trademarks of Sky Limited and Sky International AG and are used under licence.

Sky UK Limited (Registration No. 2906991), Sky-In-Home Service Limited (Registration No. 2067075), Sky Subscribers Services Limited (Registration No. 2340150) and Sky CP Limited (Registration No. 9513259) are direct or indirect subsidiaries of Sky Limited (Registration No. 2247735). All of the companies mentioned in this paragraph are incorporated in England and Wales and share the same registered office at Grant Way, Isleworth, Middlesex TW7 5QD