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

From: Stephen Farrell <[email-masked]>
Date: Sat, 4 Jan 2020 16:20:35 +0000

Hiya,

The verbosity and lack of agreement and clarity on the list
since this was posted has convinced me that this is not a
viable charter.

That said, some (mostly negative, sorry;-) comments
below...

Cheers,
S.

On 20/12/2019 15:20, Ben Schwartz wrote:
> Hello ADD list,
> 
> Based on the feedback from the ABCD BoF at IETF 106, and with additional
> input from chairs and area directors from relevant working groups, the ABCD
> BoF chairs have drafted the following updated charter for a working group.
> Please review it and share your perspective.
> 
> Tommy Pauly has recently posted a charter text proposal that considers
> closely related issues. This is not a competition, so please avoid “voting”
> for one proposed text over the other.  The text of any final charter will
> be written by the IESG.  To help them judge whether a working group should
> be formed, and how it should be chartered, the most productive input would
> be to know which elements of each text you find valuable (if any), and
> which you would like to see changed in any final charter.

Tommy's proposal has the benefit of covering fewer topics.
I think that's (fewer topics) likely a requirement if any
progress is to be made.

> 
> -----------------------------------
> 
> Proposed charter text:
> 
> This working group will focus on DNS client side topics, particularly
> discovery and selection of resolvers. This complements existing DNS-related
> working groups, which are responsible for improvements to the DNS protocol
> itself, and for operational questions that are principally of interest to
> DNS server operators.

I like that you've tried to provide a logical functional
basis for what to in/exclude in the WG. However, my take
is that success/failure will be much more driven by the
non-functional aspects (e.g. cat-herding, not biting off
more than can be chewed) so I'm not sure this is needed,
even if it's clever;-)

> 
> The working group is chartered to develop an extensible protocol for a DNS
> client to learn detailed information about a resolver, based on
> draft-ietf-dnsop-resolver-information, which will be transferred from
> dnsop.

Using that to discover that a recursive offers DoT/DoH
seems to provide, at best, opportunistic security. But
I like opportunistic security approaches, where they're
useful, and it could be useful here, in some networks.
In other networks and for some applications, the OS
approach will provide no substantive benefit.

For opportunistic security to be useful also needs at
least a story/plan for how to get to something better. So
I think there's a major missing part here about
re-visited networks. (Even if aspects of that are
implementation-specific, the story is needed before we
know the opportunistic staging post is useful.)

I think a wg that doesn't start out with an agreed
understanding as to whether or not discovery being
opportunistic is ok or not will fail. There may even
be a need to catalog the various possible setups and how
discovery plays out in each in order to make progress.
(Recent list discussion with unqualified uses of the
term "trust" along with ambiguous pronouns seems to
indicate that may be needed.)

Even with all that, I'm not clear what'd motivate an
application (whether a browser or something else) to want
to do this, though I can see this possibly being useful
for a system or OS stub. I could also see some applications
using this as a way to be seen to be "doing something." All
that said, the "useful" here doesn't seem like a huge win
really in many networks. (IOW, if someone thinks defining
this will stop applications using their own choices of DoH
server, my guess is that that's wishful thinking.)

I don't understand the information leakage aspects of this, if a
non-updated recursive forwards the queries upward, nor
potential attacks (on stubs, launched by/via recursives)
this might enable. (E.g. does the nxdomain for the first
a.b.c.10.in-addr.arpa mean no other e.f.g.10.in-addr.arpa
will be forwarded for the TTL?)

I'm not convinced this putative wg is the right place to
develop an extensible protocol like this - dnsop seems much
better suited really, so I'd argue to leave that draft
in dnsop.

> Relying on this new protocol where appropriate, the working group
> should produce standards-track, informational, or experimental documents
> that provide the following items, using the drafts in brackets as input
> (with no obligation to adopt them):
>  * methods for a recursive resolver to advertise support for an alternative
> transport protocol [draft-sah-resinfo-doh],

The security considerations of that seem to me to make it
either pointless (already doing DoT/DoH) or impossible
(DNSSEC for 10.in-addr.arpa).

>  * methods for a recursive resolver to indicate that it will sometimes
> return DNS results that are different from the global DNS
> [draft-grover-add-policy-detection],

That bit seems ok, though canaries are fragile of course.
It's not clear to me that needs to be in the same WG as
the recursive discovery bits, but it could be.

I don't get why both TBD.arpa and <reverse-ip>.arpa would
need to be supported by recursive developers. ISTM one
kind of oddball qname for this stuff ought suffice for all
of the things envisaged in these drafts.

>  * methods for improving user privacy by avoiding DNS queries that leak
> information or directing them to a server that will have this information
> anyway [draft-pauly-dprive-adaptive-dns-privacy], and

I think that draft by itself (and what it implies) is
already the meat for an ambitious WG.

>  * a format for describing the client’s DNS configuration, suitable for
> diagnostics and debugging.

I'm not clear why this is needed.

Attempting all of the above is IMO way too ambitious given
the divergent interests and trust models visible in folks
postings to this list over the last 8 months.

> 
> Where possible, any mechanisms that specify exchange of information between
> clients and resolvers should provide the security properties expected of
> IETF protocols, e.g., confidentiality protection, integrity protection, and
> authentication with strong work factor.  Each specification must clearly
> indicate under what circumstances and assumptions these properties are or
> are not provided.

I'm not sure why including that boilerplate-like text is
a good idea.

> This working group will coordinate and share WGLC announcements with the
> following working groups: dnsop, capport, dprive, dhc, and homenet. The
> working group will also coordinate with the Security Area, and will be
> assigned a security advisor.

Assigned security advisors aren't that useful I think. The
person concerned is either interested or not, if they are
they'll not be shy. If they're not, they'll not be useful.

> 
> P.S. One note regarding this proposal: the chairs of the doh working group
> expect that doh would be closed if a new working group were chartered in
> this manner or similar.
> 
>

---

From: "Mirja Kühlewind (IETF)" <[email-masked]>
Date: Mon, 6 Jan 2020 14:53:45 +0100

Hi all,

I agree with Stephan in that I would prefer a more scoped charter.

I see a lot of interest in the ideas around the adaptive DNS work and I think we should build a charter that targets exactly that, as proposed by Tommy, to make sure that at least this piece of concrete work can move forward (quickly).

Other topics/problems can go in to other existing or new working groups. Especially topics related to documenting operational practices, as mentioned below in the charter, we already have a working group for and these topics should be discussed that group, nann my rly dnsops (potentially leading to some rechartering of that group in order to make clear that aspects related to operating and maintaining encrypted DNS traffic and DNS servers are in scope).

Mirja

> Am 04.01.2020 um 17:20 schrieb Stephen Farrell <[email-masked]>:
> 
> 
> Hiya,
> 
> <0x5AB2FAF17B172BEA.asc>
> -- 
> Add mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/add

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Jan 2020 14:06:58 +0100 (CET)

> Il 06/01/2020 14:53 Mirja Kühlewind (IETF) <[email-masked]> ha scritto:
> 

I really disagree with this idea. The release and early deployment of DoH opened up many non-technical issues that need a few missing technical pieces to be addressed, starting from a resolver discovery and selection mechanism that makes it possible to deploy encrypted DNS within the existing network architectures, without changing the resolver operator and without requiring the operator to be vetted by a third party. It would be kind for the IETF to work on that as soon as possible and show to the other stakeholders that it cares about all the complaints that have been publicly made for the last ~18 months.

Not doing that, and rather working on yet more technology that exacerbates the issues by disrupting more of the existing DNS and network architectures, would IMHO not be a very constructive course of action.

-- 
 
Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked] 
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 14:21:21 +0100

Hi Vittorio,

The charter proposed by Tommy (see [1]) is exactly focusing on discovery and selection. What are you missing there?

Mirja

[1] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w

> On 8. Jan 2020, at 14:06, Vittorio Bertola <[email-masked]> wrote:
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2020 05:23:07 -0800

On Jan 8, 2020, at 5:06 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> The release and early deployment of DoH opened up many non-technical issues that need a few missing technical pieces to be addressed, starting from a resolver discovery and selection mechanism that makes it possible to deploy encrypted DNS within the existing network architectures, without changing the resolver operator and without requiring the operator to be vetted by a third party.

In order to address this problem, the operator of a host using this mechanism would need to explicitly configure a trust relationship with the operator.   Are you okay with that being part of the solution?

---

From: "Ralf Weber" <[email-masked]>
Date: Wed, 08 Jan 2020 15:17:11 +0100

Moin!

On 8 Jan 2020, at 14:23, Ted Lemon wrote:
> In order to address this problem, the operator of a host using this 
> mechanism would need to explicitly configure a trust relationship with 
> the operator.
Why? Is changing DNS traffic from unencrypted to encrypted considered a 
bad idea? Requiring additional configuration on the end devices will 
lead to centralisation and thus reduce privacy. We have less OS/App 
vendors then we have networks, which currently provide name resolution 
and I think we agree that the average user can’t make that decision, 
and even if they could we don’t have nowhere near the number of 
choices on DoH services that we have on networks providing regular DNS 
and might be willing to provide encrypted DNS via DoH or DoT for their 
users.

All current deployment stratgeies for DoH are only considering globally 
available DoH servers, rather then per network servers that don’t 
serve other users. Network only DoH servers would be much better from 
privacy perspective as networks and end users often have a business 
relationship, and also could be scaled more easily making them more 
likely to appear.

So long
-Ralf
—--
Ralf Weber

---

From: Vittorio Bertola <[email-masked]>
Date: Wed, 8 Jan 2020 16:20:27 +0100 (CET)

> Il 08/01/2020 14:21 Mirja Kuehlewind <[email-masked]> ha scritto:
> 

I think there partially is an issue of wording - the term "adaptive DNS", which you used to indicate the focus of the new work, to me indicates the architecture in Tommy's draft, which has the conceptual, non-technical problems I mentioned. Of course it is also a form of "discovery and selection", but in an opposite direction than the one that would address the problems that many of us have raised.

--

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 16:32:59 +0100

I think any discussion about selection policy (where e.g. one policy could be to always prefer the resolver of your local operator if encryption is offer), should take place in the new working group and not at charter time. Maybe there is small change we can make to the charter to ensure that people don’t think this option is excluded?

Mirja

> On 8. Jan 2020, at 16:20, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:
> 
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 8 Jan 2020 08:34:51 -0800

As I (and a number of others) have said, I believe we should explicitly
keep such questions of policy out of scope. It seems quite clear we're not
going to get anywhere near consensus on them, so it's just a recipe for a
WG that doesn't do anything productive. I think it's fine to have a charter
to develop mechanisms for discovery

-Ekr

On Wed, Jan 8, 2020 at 7:33 AM Mirja Kuehlewind <[email-masked]> wrote:

> I think any discussion about selection policy (where e.g. one policy could
> be to always prefer the resolver of your local operator if encryption is
> offer), should take place in the new working group and not at charter time.
> Maybe there is small change we can make to the charter to ensure that
> people don’t think this option is excluded?
>
> Mirja
>
>
>
> > On 8. Jan 2020, at 16:20, Vittorio Bertola <vittorio.bertola=
> [email-masked]> wrote:
> >
> >
> >> The charter proposed by Tommy (see [1]) is exactly focusing on
> discovery and selection. What are you missing there?
> >
> > I think there partially is an issue of wording - the term "adaptive
> DNS", which you used to indicate the focus of the new work, to me indicates
> the architecture in Tommy's draft, which has the conceptual, non-technical
> problems I mentioned. Of course it is also a form of "discovery and
> selection", but in an opposite direction than the one that would address
> the problems that many of us have raised.
> >
> > --
> >

---

From: Mirja Kuehlewind <[email-masked]>
Date: Wed, 8 Jan 2020 18:03:17 +0100

Hi Ekr,

I see your concern about having an endless discussion about possible policies. And I agree that the proposed group might not be the right place for it. However, when we say policy that is a quite generic term. As I already said, I think questions about which policy to use where should be discussed in an OPS group and we already have an OPS group for DNS. However, I also don’t think we can design discovery mechanism without having certain policies in mind. So having a certain set of policies that can be supported by the section mechanism that uses the discovery mechanism has to be defined. Adaptive DNS, as proposed currently, implicitly defines a default policy that would, if not configured otherwise, prefers the designated resolver. However, this is not put as a requirement in the charter and something that can be further discussed in the working group.

I also support to keep the part of communicating local policy as currently in the proposed charter. I think this is especially important for enterprise or otherwise more closely managed/trusted network. I’d be okay to limit the charter to that use case initially, as it might be good to focus discussion, but I think it is important to have that use case in mind when design discovery mechanisms.

Mirja

> On 8. Jan 2020, at 17:34, Eric Rescorla <[email-masked]> wrote:
> 
> As I (and a number of others) have said, I believe we should explicitly keep such questions of policy out of scope. It seems quite clear we're not going to get anywhere near consensus on them, so it's just a recipe for a WG that doesn't do anything productive. I think it's fine to have a charter to develop mechanisms for discovery
> 
> -Ekr
> 
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2020 09:54:55 -0800

On Jan 8, 2020, at 9:03 AM, Mirja Kuehlewind <[email-masked]> wrote:
> I also support to keep the part of communicating local policy as currently in the proposed charter.

This statement contains an embedded assumption that you may not be aware of: that it makes sense for the network to communicate resolver configuration policy to clients.   I don’t think this is an assumption that we generally agree on.

The usual counterexample given is that I definitely don’t want Starbucks to tell me what resolver configuration policy I must use.   We tend to go around and around on this, and it’s not something we can ever agree on.  I think this is a big part of ekr’s reason for saying we shouldn’t put this in the charter, and I agree with that.

It could make sense to make a list of possible policies that could be configured on a host, and talk about how to address those policies.  One of those policies could be “trust what the network says.”   This would make sense on infrastructure devices.   However, even in this case it would make sense to have a way to actually establish trust, and not just assume trust.   E.g., for Thread networks, there is a commissioning process.   If we wanted a Thread device to use DoH (not clear we want that, but just as an example), then the trust establishment process could be done automatically when the device is commissioned onto the network.

So practically speaking, I don’t actually see any reason why we’d ever want to encourage a protocol that would allow the network to replace a trusted resolver configuration with an untrusted resolver configuration.   And the problem seems to be that some people participating in this discussion, whether out of ignorance or conviction, are in fact arguing that we should put that in the charter.

---

From: Rob Sayre <[email-masked]>
Date: Wed, 8 Jan 2020 10:16:16 -0800

On Wed, Jan 8, 2020 at 9:55 AM Ted Lemon <[email-masked]> wrote:

> So practically speaking, I don’t actually see any reason why we’d ever
> want to encourage a protocol that would allow the network to replace a
> trusted resolver configuration with an untrusted resolver configuration.
> And the problem seems to be that some people participating in this
> discussion, whether out of ignorance or conviction, are in fact arguing
> that we should put that in the charter.
>

Adding to that: I seriously doubt proposals that change the resolution
order in Adaptive DNS would be productive. When I read that draft, it seems
like more of a description of what's going to happen (and is happening in
an ad-hoc way), rather than a design decision a WG might productively
debate.

thanks,
Rob

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Wed, 8 Jan 2020 21:34:16 +0000

From: Ted Lemon

>  So practically speaking, I don’t actually see any reason why we’d ever want to encourage a
>  protocol that would allow the network to replace a trusted resolver configuration with an 
>  untrusted resolver configuration.   

Who gets to define "trusted resolver"? 

I, personally, have made a choice to allow my ISP to use my DNS queries to create a profile of me for more targeted ads (this doesn't increase the number of ads -- it just makes them more relevant to me). I'm not alone in this. There are many people who prefer for the ads they see to be more relevant. There are also people who find targeted ads creepy. My ISP provides me with a web page where I can make this choice. My ISP also tells me "Unless you give us explicit permission, we don’t sell data that directly identifies you." I haven't given such explicit permission. To me, there's a huge difference between selling my data and selling an ad based on my data. How I define privacy for me is my decision. Not anyone else's. 

I'm also pretty sure the enterprise trusts their own resolver for use in their network more than they trust a quad-n resolver.

Why, indeed, are we encouraging a protocol that can be used by applications to replace the resolver I and enterprise network operators trust with one that we don't?

However, I do think it would be useful to see if we can come up with a reasonable way to communicate resolver policy. Even if it's just a url where you can indicate your privacy preferences when using that resolver.
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2020 14:40:38 -0800

On Jan 8, 2020, at 1:34 PM, STARK, BARBARA H <[email-masked]> wrote:
> Who gets to define "trusted resolver”?

A trusted resolver is a resolver that you are able to securely identify, and for which you have configured a trust relationship.   You being the end-user, if they are savvy, or the host vendor if the end-user is not savvy, or, as I suggested two messages back, a relationship established as a result of the commissioning process for an infrastructure device.

> I, personally, have made a choice to allow my ISP to use my DNS queries to create a profile of me for more targeted ads (this doesn't increase the number of ads -- it just makes them more relevant…

OK.  Wouldn’t it be nice to be able to explicitly configure this, rather than relying on a completely non-secure configuration process to hopefully set it up the way you want?   That is, if you think you are trusting your ISP, but in fact your home router has been pwned and is sending all your traffic to a third party, wouldn’t you want to know that that was happening?   Wouldn’t you want it to fail?   In order to do that, you have to be able to configure a verifiable trust relationship.

> I'm also pretty sure the enterprise trusts their own resolver for use in their network more than they trust a quad-n resolver.

Indeed.  And enterprise IT departments have onboarding processes, during which verifiable trust relationships can be explicitly established.

> Why, indeed, are we encouraging a protocol that can be used by applications to replace the resolver I and enterprise network operators trust with one that we don’t?

I don’t follow.   What do you mean?   Are you saying we should get rid of DoH?

> However, I do think it would be useful to see if we can come up with a reasonable way to communicate resolver policy. Even if it's just a url where you can indicate your privacy preferences when us…

If it’s not verifiable, then you configuring a choice doesn’t have any verifiable effect, so what’s the point?  If you don’t care about the trustworthiness of your resolver, you can just use DHCP.

---

From: "Glenn Deen" <[email-masked]>
Date: Wed, 08 Jan 2020 15:47:50 -0800

I’ve been working on this note for the last 2 days, going back and 
forth trying to layout a path forward for ADD/ABCD. I’m sure it is not 
perfect, but you wait for perfection you’ll never move productively 
forward.   Please try to be kind when responding.

As it standards currently there are two ABCD charter proposals  [1] 
https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw 
and [2] 
https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w  
which have the same top level goal:  Discovery and Selection of 
Resolvers by a DNS Client, but they differ in the specific description 
of deliverables as well as what they prescribe as the starting point and 
approach.   For full disclosure I was a contributor to (1), but that 
said I see common goals exist across both which gives me hope.

The discussion seems to be stuck with people talking past one another, 
and a lack of focus on how to move forward.  My intention is to try to 
break that pattern by first breaking down why this is even being 
discussed and then proposing a path forward.

Why we are discussing this
————————————————————-—————

The real world deployment of the changes driven by Encrypted DNS 
technologies like DoH and DoT and other changes being proposed like 
Adaptive DNS and Ubiquitous DNS are being the need for Discovery and 
Selection of DNS Resolvers.  So this is neither an academic exercise nor 
engineers wanting to change things for the sake of change.

The need for Discovery and Selection of Resolvers by a DNS Client has 
been raised on this list, at microphones, and on other lists such as the 
EDDI Encrypted DNS Deployment Initiative list and meetings.    The input 
has come from a broad set of contributors that come from a wide cross 
section of the participants who care about DNS including major browser 
makers, OS makers, network operators,  DNS operators, and others from 
enterprises, and dare I say even it, from users too.

We’ve even had a number of drafts submitted to DNS OPs and DNS Priv

So while I acknowledge that there is not 100% agreement on the above, as 
if there ever is in such things, there does seem to a tremendous amount 
of interest in the need for Discovery and Selection, as well as a broad 
and diverse set of contributors wanting to work on it, and we have 
groups actually working on building and deploying solutions as well.

The conclusion is that there is a community of interest, contributors, 
and adopters here, and the work is going to be done somehow and 
somewhere which leaves the question for the IETF being the outstanding 
questions of what part of that work is to be done with the IETF, what 
exactly is the scope of that work?

Having caught up on the proposals, suggestions, and comments it seems 
that perhaps the biggest barrier is in trying to create the optimized 
charter of deliverables, scope, and with prescriptive and proscribed 
approaches that satisfies the various diverse views while also trying to 
proscribe in how the WG shall do it. Essentially the various drafts have 
elements of trying preemptively manage the WG’s work before the WG has 
a change to meet and engage.  Each of the proposals cites one or more 
specific drafts as the basis for the work, and that in turn seems to be 
causing a lot of the debate as that level of prescription to the WG sets 
proponents of the other approaches off.

Getting back to making progress
———————————————————————————————

I’d suggest that perhaps the approach of being too proscriptive in the 
charter is not going to succeed and instead of trying to create the 
optimal charter that assuages the various wants, fears, and hopes that 
people have put out on the list, that we alternatively it approach it a 
simpler way. - a key part of which will involve trusting the IETF 
process and ourselves to work together to consciously do the right 
thing.

Instead of trying to put just the right words into the charter have 
upfront cover every possible aspect and contingency as if the charter 
itself was code, we do the following:

(1) Create a charter with a clear, yet simple goals.

(2) Create simple clear boundaries.

(3) Let the WG members do the work of bringing together the various 
proposals and discuss and work through the use-cases, needs, and 
technical issues.  Do not be overly detailed or proscriptive in the 
charter, and let it organically evolve as needed via  the WG 
participants and under the WG Chairs management and oversight of the 
ADs.  Part of the problems in the previous attempts has been trying to 
skip past this hard work by being proscriptive in the charter.  This has 
resulted in non-productive back and forth on the list instead of focused 
discussion on the specifics in drafts.

(4) Trust in the IETF process and give the chance for the WG Chairs and 
the ADs to work together to manage the WG activity and to keep it on 
track. Give the chairs the mission and ability, under the ever watchful 
and wise guiding hands of the ADs, to manage the WG toward the focused 
goal delivering the Discovery and Selection functionality that DNS 
Clients need in deployments.

(5) Remove any boiler plate or unneeded assertions, comments, guidance, 
as well as anything that it obvious.   A great example of something 
obvious is saying in the charter that the WG will coordinate with other 
groups or security area, because quite obviously they will, for there 
isn’t any other choice is the WG is actually going to produce 
documents that have a hope of getting approval in the IESG.

If we did that then this is how this 5 points could play out:

1. Clear, yet simple goal such as:

    The WG will work on the problems of Discovery and Selection of 
Recursive Resolvers by DNS Clients.

    The goals of the group are to:

    (1) Produce mechanisms which will enable a DNS Client to discover 
the recursive resolvers available to
        it in the network environment it is connected to, with 
recognition that the network environment for
        a DNS Client can change overtime such as a device moving between 
different networks environments
        such as a home, an office, and a public space such as a cafe, or 
others as identified by the WG.

    (2) Produce a framework where the DNS Client can obtain the 
information needed by the client to select
        the DNS resolvers it chooses to use.

2. Simple clear boundaries, such as:

     The WG will limit its work to the technical aspects of discovery 
and the technical aspects of the selection framework
     for DNS/53, DoH, and DoT operational environments.

     The WG is not chartered to work on non-technical areas such as 
policy, except the conveyance of whatever policy
     information in the selection framework to enable DNS Clients to 
make their selection.

     The WG is not charted to work on security, or privacy problems 
beyond those essential to Discovery or Selection.

3. Let the WG do the work

     This means the WG won’t be told via that charter what WG drafts 
or architectures it must start from.

     The WG would open the floor to drafts for consideration that cover 
both proposals for Discovery or Selection,
     As well a problem statement drafts and use-case drafts that would 
present the functional needs and considerations
     that the Discovery mechanisms, and Selection framework would need 
to satisfy.

     This will be drive the discussion hopefully to be technical and 
about specifics and get away from the ADD list issues.

4.  Trust in the IETF process

     Hopefully the ADs will appoint WG chairs that are willing to stay 
above the fray and focus on managing the WG process.

5.  Remove any boiler plate or unneeded assertions, comments, guidance, 
as well as anything that it obvious.

     See the above proposal under point (1) Clear, yet simple goal.

     This is a technical working group that will be run with hands on 
supervision.  The charter isn’t a legal statue
     that we need to avoid legal loopholes in, it’s not going to 
litigated, and the AD’s and IESG  can always
     Choose to refine the mission or even close the WG if it goes off 
the rails.   We have a tried and proven
     process to manage this sort of work; Let’s use it and get to 
work.

This all comes together in the shaved down WG charter proposal:

    The WG will work on the problems of Discovery and Selection of 
Recursive Resolvers by DNS Clients.

    The goals of the group are to:

    (1) Produce mechanisms which will enable a DNS Client to discover 
the recursive resolvers available to
        it in the network environment it is connected to, with 
recognition that the network environment for
        a DNS Client can change overtime such as a device moving between 
different networks environments
        such as a home, an office, and a public space such as a cafe, or 
others as identified by the WG.

    (2) Produce a framework where the DNS Client can obtain the 
information needed by the client to select
        the DNS resolvers it chooses to use.

     The WG will limit its work to the technical aspects of discovery 
and the technical aspects of the selection framework
     for DNS/53, DoH, and DoT operational environments.

     The WG is not chartered to work on non-technical areas such as 
policy, except the conveyance of whatever policy
     information in the selection framework to enable DNS Clients to 
make their selection.

     The WG is not charted to work on security, or privacy problems 
beyond those essential to Discovery or Selection.

- that’s it folks —

And we call it DNS-DS  (DNS Discovery and Selection)

Are there interesting topics and aspects of DNS being left out of this?  
Absolutely, and for those there is DPRIV and DNS-OPS etc. They remain 
the places to discuss those other things as appropriate.  This WG is 
just about D&S.

Time is ticking away and IETF107 in Vancouver is now only 10 weeks away. 
   We could spend 10 more weeks talking past one another, or we could 
settle on what needs to be done, hopefully get the ADs/IESG to buy in, 
and get down to work.

-Glenn Deen

[1] 
https://mailarchive.ietf.org/arch/msg/add/QWli5buXDcRTqZ4Iv8GaOGtRbUw
[2] 
https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 9 Jan 2020 00:07:03 +0000

Hi Glenn,

Good try. Thanks.

On 08/01/2020 23:47, Glenn Deen wrote:
> (1) Produce mechanisms which will enable a DNS Client to discover the
> recursive resolvers available to it in the network environment it is
> connected to, with recognition that the network environment for a DNS
> Client can change overtime such as a device moving between different
> networks environments such as a home, an office, and a public space
> such as a cafe, or others as identified by the WG.

I'm not 100% sure, but I strongly suspect that the above
could turn into another set of ratholes if it's not clear
from the charter whether or not insecure or opportunistic
methods for discovery are ruled in or out. Yet, trying to
determine that now is also likely a rathole;-(

Could there be a way out via something like "Discovery
mechanisms that could disimprove security or privacy in
many existing networks are not in-scope. Mechanisms that
'do no worse' may (or may not) be acceptable subject to
normal IETF rough consensus, (and it will be rough;-),
processes"?

Other than that, I'd be ok with such a charter and with
other stuff being processes in dnsop or dprive as may make
sense.

S.

> information needed by the client to select the DNS resolvers it
> chooses to use.
> 
> 
> The WG will limit its work to the technical aspects of discovery and
> the technical aspects of the selection framework for DNS/53, DoH, and
> DoT operational environments.
> 
> policy, except the conveyance of whatever policy information in the
> selection framework to enable DNS Clients to make their selection.
> 
> The WG is not charted to work on security, or privacy problems beyond
> those essential to Discovery or Selection.

---

From: Brian Dickson <[email-masked]>
Date: Wed, 8 Jan 2020 18:12:48 -0800

On Wed, Jan 8, 2020 at 2:40 PM Ted Lemon <[email-masked]> wrote:

> A trusted resolver is a resolver that you are able to securely identify,
> and for which you have configured a trust relationship.   You being the
> end-user, if they are savvy, or the host vendor if the end-user is not
> savvy, or, as I suggested two messages back, a relationship established as
> a result of the commissioning process for an infrastructure device.
>
> I, personally, have made a choice to allow my ISP to use my DNS queries to
> create a profile of me for more targeted ads (this doesn't increase the
> number of ads -- it just makes them more relevant to me). I'm not alone in
> this. There are many people who prefer for the ads they see to be more
> relevant. There are also people who find targeted ads creepy. My ISP
> provides me with a web page where I can make this choice. My ISP also tells
> me "Unless you give us explicit permission, we don’t sell data that
> directly identifies you." I haven't given such explicit permission. To me,
> there's a huge difference between selling my data and selling an ad based
> on my data. How I define privacy for me is my decision. Not anyone else's.
>
>
> OK.  Wouldn’t it be nice to be able to explicitly configure this, rather
> than relying on a completely non-secure configuration process to hopefully
> set it up the way you want?   That is, if you think you are trusting your
> ISP, but in fact your home router has been pwned and is sending all your
> traffic to a third party, wouldn’t you want to know that that was
> happening?   Wouldn’t you want it to fail?   In order to do that, you have
> to be able to configure a verifiable trust relationship.
>
>
There are a number of problems that I think can be addressed, that are
worth pursuing relative to these questions.
Not all of them can be completely solved, IMHO, but it may be possible to
at least scope the problems or constrain the risk parameters at play.

I think the starting point is some manner of user/machine/application
"policy" (or policies), keeping things as simple as possible without
ignoring real areas of contention.
Concrete examples off the top of my head:

   - Having policies that can be managed (on managed devices) would be
   good.
   - Having policies that are in some manner tied to network identity or
   SSID, in terms of trust. Those are only as valuable as the ability to
   securely validate IDs.
   - Policies regarding preference of encrypted vs unencrypted DNS server
   (if more than one is available/known).
   - The ability for the client to assess the immediate environment,
   including passively or actively interacting with network elements (e.g.
   DHCP), and doing various kinds of discovery.

There are some kinds of sanity check that would be good to apply, that
would potentially be useful for alerting the user about what has been
discovered.
There are also ways of limiting the need to trust the local server, without
having to change the default resolver. Specifically, if the local server is
merely a forwarder, then discovering the upstream resolver would be
valuable.
Having the ability to bypass the forwarder means that any subsequent pwning
of the router would be either inconsequential (since it isn't being used
for DNS), or automatically detected (if it forwards all DNS traffic or all
traffic, since it would break DoT/DoH).

Another example where client discovery would be useful, regardless of the
trust/security involved, is determining the latency to the resolver.
Speed of light is pretty much a constant, so a lower bound on distance to
the resolver can be easily established.
Reporting to the client (user) that the resolver is not on the same
continent, or not in the same metro area, or same time zone, is valuable
regardless of the state of privacy/trust, particularly in the absence of
configured resolvers.

The trust relationship may be ephemeral, but may also be sufficient for
many use cases. Reducing the risk to a level where the client is only at
risk the first time the device is powered on, and only if the local network
is pwned, is certainly a good baseline for better goals, and I think it's
something that is achievable without too much work.

Whether a given network should be trusted, is very much dependent on a
combination of things: host profile (e.g. default provided by the
manufacturer or OS vendor); user profile (e.g. managed by an employer);
network profile (absent any other profiles); and application profile(s).

To me, the question isn't whether a particular entity wants to supply a
non-default value; it is whether any non-default policies exist, and the
question of how multiple such policies can be suitably resolved.

I think we can exclude the "multiple policies conflicting" aspect as out of
scope, mostly, so long as we give appropriate consideration to handling a
single non-default policy among all the potential scoped defaults or
policies.

Those policies might themselves include how to resolve such conflicts, in
which case it might be sufficient to spec out the syntax and semantics of
that, and expect all components of the system to honor whatever the policy
is.

If we assume generally multi-user devices, then what would seem to me to
make the most sense is device-wide > user > app > network, where any
higher-scope element can bypass the lower-scoped things to establish its
own "rules".
A device can configure itself to trust the network (and not be over-ridden
by any user).
A device without any such config, could be managed by the user (to manual
configure something, or prefer the config by some particular app, or to
have per-network selections used).
If no user preferences (or overrides/logic) are used, then each app would
be free to do its own thing.
And lastly if no app is doing anything, default network behavior gets used
(with lowest prevalence/priority), i.e. only if nothing else takes control
of the policy.

IMHO, the only time it is reasonable for an app to assert policy control,
is in the absence of user or device policy assertion (possibly including
vendor-standard policies which may differ by vendor.)

Brian

> I'm also pretty sure the enterprise trusts their own resolver for use in
> their network more than they trust a quad-n resolver.
>
>
> Indeed.  And enterprise IT departments have onboarding processes, during
> which verifiable trust relationships can be explicitly established.
>
> Why, indeed, are we encouraging a protocol that can be used by
> applications to replace the resolver I and enterprise network operators
> trust with one that we don’t?
>
>
> However, I do think it would be useful to see if we can come up with a
> reasonable way to communicate resolver policy. Even if it's just a url
> where you can indicate your privacy preferences when using that resolver.
>
>
> If it’s not verifiable, then you configuring a choice doesn’t have any
> verifiable effect, so what’s the point?  If you don’t care about the
> trustworthiness of your resolver, you can just use DHCP.
>
> --
> Add mailing list
> [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 8 Jan 2020 18:46:50 -0800

On Jan 8, 2020, at 6:12 PM, Brian Dickson <[email-masked]> wrote:
> Having policies that can be managed (on managed devices) would be good. 
Agree
> Having policies that are in some manner tied to network identity or SSID, in terms of trust. Those are only as valuable as the ability to securely validate IDs.
This is unnecessary.  You’re connecting using TLS.  Just validate the server’s cert.  The trust establishment process just configures the server’s identity, you validate the cert, and Bob’s your uncle.  This is not hard.
> Policies regarding preference of encrypted vs unencrypted DNS server (if more than one is available/known).
I think this is out of scope.  The audience here would be vendors like Apple, Google, Microsoft, Mozilla, etc.  Why would they listen to the IETF’s pontifications on how best to serve their users?   If you mean configuring hosts via the network with these policies, then you have a mechanism for overriding trust relationships by an untrusted network, which we obviously can’t do. 

If you mean providing a way to securely install provisioning profiles that implement these policies, then that seems okay.   The challenge here is that I suspect work is being done on this right now by at least some, if not all, of the vendors I mentioned.  I think trying to say how this should go right now in the absence of much experience isn’t likely to produce a useful document.

> The ability for the client to assess the immediate environment, including passively or actively interacting with network elements (e.g. DHCP), and doing various kinds of discovery.

This is already covered by the MPvD work (RFC7556, draft-ietf-intarea-provisioning-domains-10, which is on the January 23 IESG telechat).

---

From: Vittorio Bertola <[email-masked]>
Date: Thu, 9 Jan 2020 11:16:53 +0100 (CET)

> Il 09/01/2020 01:07 Stephen Farrell <[email-masked]> ha scritto:
> 

If this means "anything not worse than today should be supported", I think I can live with it (and, in general, I can live with Glenn's proposal, though of course I am not 100% happy with it). But that would require changing your "may (or may not)" :-)

The point is that we start from an existing model, we want to upgrade the security of the transport protocol, but some people say: while we are at it, we could also improve the security of the resolver discovery mechanism by not discovering at all, or by only discovering among a set of pre-trusted options, and by preventing the network from applying any policy, as that might be used to attack the user.

However, others think that local network policies generally increase the security of the Internet access service, so doing the above will decrease the overall security by removing the network operator's ability to use the DNS to monitor traffic, discover ongoing attacks and prevent connection to infected websites. So they would rather not get the increased security in the discovery mechanism, but also not lose the security provided by the network operator through the resolver; they would like to be able to upgrade the transport protocol without changing the discovery mechanism, except for what is necessary to communicate the existence of an encrypted version of the local resolver.

In the end, this is a tradeoff that depends on context and user preferences, and I do not think that we will ever get to agreement on which option is best - not to mention the fact that the choice also impacts on privacy, competition, jurisdiction and other non-technical dimensions, where other non-technical stakeholders will definitely want to have a say. 

So it would be good if we, as a compromise, agreed that both options are ok, that we need to have technology that can support both of them, and that our arguments on which one is best, or even acceptable, should be better moved outside of the IETF.

--

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 9 Jan 2020 11:53:34 +0000

Hiya,

On 09/01/2020 10:16, Vittorio Bertola wrote:
>> I'm not 100% sure, but I strongly suspect that the above could turn
>> into another set of ratholes if it's not clear from the charter
>> whether or not insecure or opportunistic methods for discovery are
>> ruled in or out. Yet, trying to determine that now is also likely a
>> rathole;-(
>> 
>> Could there be a way out via something like "Discovery mechanisms
>> that could disimprove security or privacy in many existing networks
>> are not in-scope. Mechanisms that 'do no worse' may (or may not) be
>> acceptable subject to normal IETF rough consensus, (and it will be
>> rough;-), processes"?
> 
> If this means "anything not worse than today should be supported", I
> think I can live with it (and, in general, I can live with Glenn's
> proposal, though of course I am not 100% happy with it). But that
> would require changing your "may (or may not)" :-)

No, I didn't mean should, I did mean may. Arguing for
should here puts us back in rathole territory where we
end up endlessly debating which inaccurate abstraction
is best, knowing all the time that "none of them" is
the correct answer.

> 
> The point is that we start from an existing model, we want to upgrade
> the security of the transport protocol, but some people say: while we
> are at it, we could also improve the security of the resolver
> discovery mechanism by not discovering at all, or by only discovering
> among a set of pre-trusted options, and by preventing the network
> from applying any policy, as that might be used to attack the user.
> 
> However, others think that local network policies generally increase
> the security of the Internet access service, so doing the above will
> decrease the overall security by removing the network operator's
> ability to use the DNS to monitor traffic, discover ongoing attacks
> and prevent connection to infected websites. So they would rather not
> get the increased security in the discovery mechanism, but also not
> lose the security provided by the network operator through the
> resolver; they would like to be able to upgrade the transport
> protocol without changing the discovery mechanism, except for what is
> necessary to communicate the existence of an encrypted version of the
> local resolver.
> 
> In the end, this is a tradeoff that depends on context and user
> preferences, and I do not think that we will ever get to agreement on
> which option is best - not to mention the fact that the choice also
> impacts on privacy, competition, jurisdiction and other non-technical
> dimensions, where other non-technical stakeholders will definitely
> want to have a say.
> 
> So it would be good if we, as a compromise, agreed that both options
> are ok, that we need to have technology that can support both of
> them, and that our arguments on which one is best, or even
> acceptable, should be better moved outside of the IETF.

Two points. "Both are ok" is an unlikely outcome as there
are >2 things and each is sometimes ok, sometimes not. 2nd
point is that we do already have the insecure discovery
model (DHCP/RA) widely deployed. From both of those I would
conclude that such a compromise is not a goal, but rather
the goal would be to define useful mechanisms with known
security and privacy properties, in the full knowledge that
people will continue to disagree about how best to deploy
those for quite a while yet.

Cheers,
S.

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 9 Jan 2020 13:38:11 +0100

The case I have in mind is when a managed devices is connected to a managed enterprise network and a policy is provided to enable or enforce a local function. Given the device is managed you can probably pre-install some policies but in this setup you can also preconfigure your device to know the trusted network and then communicate policies more dynamically.

I guess you can use the same communication mechanism to also distribute policy at starbucks but I would think your device would by default be configure to not accept such a policy.

I would like the first case to be considered in group working on DNS discovery. I actually don’t think it will be hard to do so by e.g. adding additional information to the PvD. If there is a way to exclude the second case (where the same protocols is used on unmanaged networks) I don’t know but I guess there is an easy way to have a local device policy to prohibit that. So I don’t think we have to decide about the policies itself at this point but I think a mechanism to communicate some policy locally is important for deployment of a more adaptive DNS.

Mirja

> On 8. Jan 2020, at 18:54, Ted Lemon <[email-masked]> wrote:
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2020 04:44:14 -0800

On Jan 9, 2020, at 4:38 AM, Mirja Kuehlewind <[email-masked]> wrote:
> you can also preconfigure your device to know the trusted network and then communicate policies more dynamically.

Yes, but what does that mean?   Do you mean that you can configure the device to accept an un-signed UDP packet configuring its name resolution setup to point at Do53 servers, even if it’s configured by default to talk to a DoT server?

> I actually don’t think it will be hard to do so by e.g. adding additional information to the PvD.

PvDs are not signed and can’t be authenticated.

> I think a mechanism to communicate some policy locally is important for deployment of a more adaptive DNS.

Can you give an example of what such a policy would look like and how it would make sense to configure it without it being authenticable?

---

From: Mirja Kuehlewind <[email-masked]>
Date: Thu, 9 Jan 2020 13:52:43 +0100

> On 9. Jan 2020, at 13:44, Ted Lemon <[email-masked]> wrote:
> 

Not in general but maybe for certain services.

> PvDs are not signed and can’t be authenticated.

Some kind of authentication should probably take place when you join the network already. However, I think that discussion should take place in a working group and I think there are people that have more expertise here than I do.

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 9 Jan 2020 16:37:13 +0000

[JL] I think we'll just keep debating what all that means. So I agree with Glenn to leave it simply as discovery and see what I-Ds emerge in the WG and debate the specifics of those documents per usual IETF process.

---

From: "Livingood, Jason" <[email-masked]>
Date: Thu, 9 Jan 2020 16:44:11 +0000

>    Who gets to define "trusted resolver"?

[JL] Trust is relative, so it changes from person to person, country to country, consumer to enterprise, etc. We will never solve this question IMO. I think this is really up to each application to decide, which may be based on direct user preferences/choice, something based on the network (e.g. enterprise), as part of the philosophy of the app (which is maybe why the user chose to use that app vs. a competing app), or anything else.

[JL] Perhaps we can simply solve the problem of how to provide a standards-based mechanism to communicate structured data to a client about things such as how a resolver operates (e.g. DNSSEC validating, DoH URL of X, DOT FQDN of Y, whatever). How the app will choose to use that information and make a selection decision seems up to the app/OS.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2020 09:05:19 -0800

> [JL] Trust is relative, so it changes from person to person, country to country, consumer to enterprise, etc. We will never solve this question IMO. I think this is really up to each application to…

It would be more accurate to say that people mean a lot of different things when they use the word trust.   You are using the word here in its natural english vernacular meaning: “do I trust the resolver to do X?”   And of course, there are lots of different things you might mean for X, so what you said is true in this sense.

However, trust in a security vernacular context means something very specific: that you have chosen to trust something.   It doesn’t matter why you have chosen to trust it, so your observation doesn’t apply here: either you’ve chosen to trust it or you haven’t.   So we can say that a thing is or is not trusted and be extremely clear about what we mean.

Secondarily, you can trust something in an arbitrary sense “I trust whatever resolver the network gives me” or in a verifiable sense “I trust resolver X, which presents identity Y, which I am able to validate.”

Again, we can discuss this quite clearly—there’s no need to be concerned about what policy might be present in what context.   If we want to be able to arbitrarily trust resolvers that are not identified, that’s a specific thing we can describe how to do.   If we want to be able to trust specific resolvers the identity of which we are able to verify, that’s a different specific thing we can describe how to do.

I’m a bit frustrated that we keep going around on this point—it would help if we could be clear about what we mean when we talk about trust.   The IETF really can’t reason about trust in the english vernacular sense, but we can and do reason about trust in the security vernacular sense.

---

From: Alissa Cooper <[email-masked]>
Date: Thu, 9 Jan 2020 14:43:50 -0500

+1

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.

Alissa

> On Jan 6, 2020, at 8:53 AM, Mirja Kühlewind (IETF) <[email-masked]> wrote:
> 
> Hi all,
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2020 12:18:47 -0800

On Jan 9, 2020, at 11:43 AM, Alissa Cooper <[email-masked]> wrote:
> [1] https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w <https://mailarchive.ietf.org/arch/msg/add/XudG5id0wwdRndR5za4G9ZbCo_w>
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.

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.

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Thu, 9 Jan 2020 21:33:03 +0000

From: Ted Lemon

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.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_add_XudG5id0wwdRndR5za4G9ZbCo-5Fw&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=PbQr2JbaxtzOWbU8OS-rZT0R23zY784b5Q8GmI19vnk&s=cLwwhC4t9V2mW0yZlCep4H9b6yDLaqFnT6lBuGLuuoY&e=>

<bhs> There would totally be a point in implementing it. There are many usage scenarios where the administrator or user of the device trusts (or can determine whether they trust) a network. Just because DHCP isn’t the right solution for all scenarios, doesn’t mean it isn’t the right solution for some (or even many) scenarios. If a user can be asked whether or not the network is public or private, or the administrator can install software that can determine if the device is on a trusted network, then the device can use a combination of admin policy and user input to decide whether or not to ask for / use DHCP options. Just because the DHCP option is provided, doesn’t mean you have to use it. If a device doesn’t use it, we’re no worse off than now, with no DHCP option specified. If the device does use it, then we’ve at least provided a solution for those usage scenarios where the network is trusted. Right now, we’re holding “networks trusted by the user/admin” hostage until some convoluted solution can be created that adds complexity and confusion for the user and only serves to shift who the user/admin has to trust (but doesn’t necessarily make things more secure or private).

OTOH, if we could figure something out that is simple (especially for the user) and doesn’t just shift who the user/admin has to trust, that would definitely be useful to explore.
Barbara </bhs>

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 9 Jan 2020 14:01:53 -0800

On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H <[email-masked]> wrote:

> *From:* Ted Lemon
> 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.
>
> <https://urldefense.proofpoint.com/v2/url?u=https-3A__mailarchive.ietf.org_arch_msg_add_XudG5id0wwdRndR5za4G9ZbCo-5Fw&d=DwMFaQ&c=LFYZ-o9_HUMeMTSQicvjIg&r=LoGzhC-8sc8SY8Tq4vrfog&m=PbQr2JbaxtzOWbU8OS-rZT0R23zY784b5Q8GmI19vnk&s=cLwwhC4t9V2mW0yZlCep4H9b6yDLaqFnT6lBuGLuuoY&e=>
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> <bhs> There would totally be a point in implementing it. There are many
> usage scenarios where the administrator or user of the device trusts (or
> can determine whether they trust) a network. Just because DHCP isn’t the
> right solution for all scenarios, doesn’t mean it isn’t the right solution
> for some (or even many) scenarios. If a user can be asked whether or not
> the network is public or private, or the administrator can install software
> that can determine if the device is on a trusted network, then the device
> can use a combination of admin policy and user input to decide whether or
> not to ask for / use DHCP options. Just because the DHCP option is
> provided, doesn’t mean you have to use it. If a device doesn’t use it,
> we’re no worse off than now, with no DHCP option specified. If the device
> does use it, then we’ve at least provided a solution for those usage
> scenarios where the network is trusted. Right now, we’re holding “networks
> trusted by the user/admin” hostage until some convoluted solution can be
> created that adds complexity and confusion for the user and only serves to
> shift who the user/admin has to trust (but doesn’t necessarily make things
> more secure or private).
>

Can you explain your threat model here? If the network is trusted, then
what are you gaining by encrypting the DNS traffic? As I mentioned, there
seem to be a few edge cases where this might have some value, but I'd like
to understand what it is you have in mind.

-Ekr

>
> OTOH, if we could figure something out that is simple (especially for the
> user) and doesn’t just shift who the user/admin has to trust, that would
> definitely be useful to explore.
>
> Barbara </bhs>
> --
> Add mailing list
> [email-masked]

---

From: Andrew Campling <[email-masked]>
Date: Thu, 9 Jan 2020 22:39:44 +0000

On Jan 9, 2020, at 21:33, STARK, BARBARA H <[email-masked]> wrote:

This seems entirely sensible: assuming that no network can ever be trusted is clearly not sensible, as is ruling out an option at this stage.  It could simplify many use cases to do so and would avoid forcing the user to trust another entity unnecessarily when doing so has the potential to introduce additional risk.

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Jan 2020 14:43:47 -0800

> This seems entirely sensible: assuming that no network can ever be trusted is clearly not sensible, as is ruling out an option at this stage.  It could simplify many use cases to do so and would av…

There is definite harm in making a charter broader than it needs to be.   If it turns out that we scoped it too narrowly, then when we have a specific use case that we agree is important but that is outside of the initial scope, we can broaden it.   This is happens frequently in the IETF.   There is no need to ever specify an overly broad charter.

---

From: Rob Sayre <[email-masked]>
Date: Thu, 9 Jan 2020 14:50:07 -0800

On Thu, Jan 9, 2020 Andrew Campling <[email-masked]> wrote:
> This seems entirely sensible: assuming that no network can ever be
trusted
> is clearly not sensible, as is ruling out an option at this stage.  It
could
> simplify many use cases to do so and would avoid forcing the user to
trust
> another entity unnecessarily when doing so has the potential to introduce
> additional risk.

"Endpoints should not depend on the confidentiality or integrity of the
carriers. Carriers may choose to provide some level of protection, but this
is secondary to the primary responsibility of the end users to protect
themselves."

RFC 1958
Architectural Principles of the Internet
June 1996

thanks,
Rob

---

From: Andrew Campling <[email-masked]>
Date: Fri, 10 Jan 2020 01:01:33 +0000

On Thu, Jan 9, 2020 Rob Sayre <[email-masked]> wrote:

> On Thu, Jan 9, 2020 Andrew Campling <[email-masked]<mailto:[email-masked]>> wrote:
>> This seems entirely sensible: assuming that no network can ever be trusted
>> is clearly not sensible, as is ruling out an option at this stage.  It could
>> simplify many use cases to do so and would avoid forcing the user to trust

> Architectural Principles of the Internet

I think that the reference to RFC 1958 underscores the problem in different perspectives in this debate: the RFC pre-dates the rise of “surveillance capitalism”; the many privacy breaches by apps (and “smart” devices); and the accelerating consolidation leading to a few corporations dominating large parts of the Internet with the consequent loss of resilience.  Therefore, the implication of RFC 1958 that it is better to rely on the confidentiality or integrity of endpoints rather than carriers is at best questionable and is certainly dated.

Andrew

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 10 Jan 2020 11:38:48 +0100 (CET)

Il 09/01/2020 23:01 Eric Rescorla <[email-masked]> ha scritto:

On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H <
[email-masked]> wrote:

Can you explain your threat model here? If the network is trusted, then what are you gaining by encrypting the DNS traffic? As I mentioned, there seem to be a few edge cases where this might have some value, but I'd like to understand what it is you have in mind.

I can't speak for Barbara, but I generally agree that encrypting the DNS transport channel is very important if you want to connect to a faraway public resolver over a network that you distrust, much less so if you want to connect to a local resolver over a trusted network (though an attacker could still manage to penetrate the local network, so there is still value in it).

But please keep in mind that there are also strong non-technical dynamics at play here. The web industry has (rightfully) spent years to convince users that "encrypted = good, unencrypted = bad". As global public resolvers go encrypted and browsers promote encrypted DNS as an important security feature, local network administrators will also be forced to encrypt communications with the local resolver, otherwise their users and their boss will cry "hey, how come our resolver is still unencrypted? you are putting us at risk!". It doesn't matter that the threat model is different - users and management will still demand encryption for the sake of encryption.

--

---

From: Eric Rescorla <[email-masked]>
Date: Fri, 10 Jan 2020 05:38:54 -0800

On Fri, Jan 10, 2020 at 2:38 AM Vittorio Bertola <
[email-masked]> wrote:

> On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H < [email-masked]> wrote:
>
> I can't speak for Barbara, but I generally agree that encrypting the DNS
> transport channel is very important if you want to connect to a faraway
> public resolver over a network that you distrust, much less so if you want
> to connect to a local resolver over a trusted network (though an attacker
> could still manage to penetrate the local network, so there is still value
> in it).
>

If the attacker penetrates the local network, they will advertise their own
resolver.

-Ekr

> But please keep in mind that there are also strong non-technical dynamics
> at play here. The web industry has (rightfully) spent years to convince
> users that "encrypted = good, unencrypted = bad". As global public
> resolvers go encrypted and browsers promote encrypted DNS as an important
> security feature, local network administrators will also be forced to
> encrypt communications with the local resolver, otherwise their users and
> their boss will cry "hey, how come our resolver is still unencrypted? you
> are putting us at risk!". It doesn't matter that the threat model is
> different - users and management will still demand encryption for the sake
> of encryption.
>
> --
>

---

From: "Smith, Kevin, Vodafone Group" <[email-masked]>
Date: Fri, 10 Jan 2020 14:47:10 +0000

> If the attacker penetrates the local network, they will advertise their own resolver.

That's certainly a valid threat. Seems like it could be mitigated by a client's Trusted Resolver table storing the pre-configured IP address for a given network's resolver - although that may result in a failure if that IP has changed for some reason. Is there another mechanism to authenticate local network recursive resolvers at the point of advertisement, and hence distinguish them from a rogue resolver in that network?

All best,
Kevin

From: Add <[email-masked]> On Behalf Of Eric Rescorla
Sent: 10 January 2020 13:39
To: Vittorio Bertola <[email-masked]>
Cc: ADD Mailing list <[email-masked]>; STARK, BARBARA H <[email-masked]>
Subject: Re: [Add] A proposed charter for ABCD

On Fri, Jan 10, 2020 at 2:38 AM Vittorio Bertola <[email-masked]<mailto:[email-masked]>> wrote:

Il 09/01/2020 23:01 Eric Rescorla <[email-masked]<mailto:[email-masked]>> ha scritto:

On Thu, Jan 9, 2020 at 1:33 PM STARK, BARBARA H < [email-masked]<mailto:[email-masked]>> wrote:
 <bhs> There would totally be a point in implementing it. There are many usage scenarios where the administrator or user of the device trusts (or can determine whether they trust) a network. Just because DHCP isn't the right solution for all scenarios, doesn't mean it isn't the right solution for some (or even many) scenarios. If a user can be asked whether or not the network is public or private, or the administrator can install software that can determine if the device is on a trusted network, then the device can use a combination of admin policy and user input to decide whether or not to ask for / use DHCP options. Just because the DHCP option is provided, doesn't mean you have to use it. If a device doesn't use it, we're no worse off than now, with no DHCP option specified. If the device does use it, then we've at least provided a solution for those usage scenarios where the network is trusted. Right now, we're holding "networks trusted by the user/admin" hostage until some convoluted solution can be created that adds complexity and confusion for the user and only serves to shift who the user/admin has to trust (but doesn't necessarily make things more secure or private).

If the attacker penetrates the local network, they will advertise their own resolver.

-Ekr

--

C2 General

Vittorio Bertola | Head of Policy & Innovation, Open-Xchange
[email-masked]<mailto:[email-masked]>
Office @ Via Treviso 12, 10144 Torino, Italy

---

From: Vittorio Bertola <[email-masked]>
Date: Fri, 10 Jan 2020 15:47:46 +0100 (CET)

Il 10/01/2020 14:38 Eric Rescorla <[email-masked]> ha scritto:

Il 09/01/2020 23:01 Eric Rescorla <
[email-masked]> ha scritto:

This depends on how and to which extent they penetrate; they could be in the position to sniff unencrypted DNS traffic, but not to advertise a resolver. But even if they were, there could be ways to develop a strengthened discovery mechanism that counters that attack; trust on first use is considered good enough for MTA-STS, Expect-CT is good enough for website certificates, why couldn't we come up with something good enough to detect unauthorized DoH resolver change/impersonation on local networks in most reasonable cases?

--

---

From: "Livingood, Jason" <[email-masked]>
Date: Fri, 10 Jan 2020 14:53:06 +0000

>If the attacker penetrates the local network, they will advertise their own resolver.

[JL] It depends. Surely there are many cases of malware changing the resolver. There have also been cases where the original resolver cache is poisoned or even where the attacker's objective is merely to passively observe traffic for whatever reason. For me, I hope that we keep going in the direction of encrypting all data in transit as a general rule.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2020 07:01:15 -0800

On Jan 10, 2020, at 6:47 AM, Smith, Kevin, Vodafone Group <[email-masked]> wrote:
> That’s certainly a valid threat. Seems like it could be mitigated by a client’s Trusted Resolver table storing the pre-configured IP address for a given network’s resolver – although that may result in a failure if that IP has changed for some reason. Is there another mechanism to authenticate local network recursive resolvers at the point of advertisement, and hence distinguish them from a rogue resolver in that network?

Yes, definitely.   I suspect the reason that Eric brought this up is that there seems to be a contingent of participants in this discussion who consider requiring that kind of validation to be too much, and would prefer to just assume that the network is secure.

> On Jan 10, 2020, at 6:47 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:

> This depends on how and to which extent they penetrate; they could be in the position to sniff unencrypted DNS traffic, but not to advertise a resolver. But even if they were, there could be ways t…

ToFU has the problem that you have to be able to securely identify the network and tie that to the trust relationship you’ve established with the network, so that you only trust that resolver when connected to the network with which you have established trust, and don’t try to use it when you are connected elsewhere (not that there would necessarily be anything wrong with that, but it might not be available).   This is complex to specify in a way that is general enough to be useable and yet specific enough not to ineffective.   I wouldn’t object to work on this, but it’s hard to believe that anybody here cares enough to get this right.

> On Jan 10, 2020, at 2:38 AM, Vittorio Bertola <vittorio.bertola=[email-masked]> wrote:

This is not a non-technical dynamic.  The reason the industry has done this is not for marketing purposes.   It’s because there are very, very serious problems with ever downloading a web page over an unencrypted connection.   Problems that cause serious problems for users, up to and including compromise of their financial accounts.

> On Jan 9, 2020, at 5:01 PM, Andrew Campling <[email-masked]> wrote:
> 

This reasoning is fallacious.  There isn’t a tension between securing the endpoints and securing the network.  Both are good.   The fact that devices have been compromised in the past is not an argument for not trying to ensure that devices are not compromised in the future.  Furthermore, the fact that devices have been compromised in the past and likely will be compromised in the future is an argument _against_ trusting the network without verification, because those compromised devices will be attached to the network: if you trust but don’t verify, those devices become an attack vector against other devices that have not (yet) been compromised.

Security tends to be compromised at the weakest link.  To get more security, protect every attack surface: don’t protect one attack surface and then rely on that to allow you to relax protection on another.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:26:57 +0100

On Wed, Jan 08, 2020 at 02:06:58PM +0100,
 Vittorio Bertola <vittorio.bertola=[email-masked]> wrote 
 a message of 26 lines which said:

> The release and early deployment of DoH opened up many non-technical
> issues that need a few missing technical pieces to be addressed,

I think one of the reasons why there are so many messages on this list
(making it hard to follow) is that there is a fundamental disagreement
at the very basis. I don't think that resolver discovery *needs* to be
addressed. The whole point of DoE (DNS over Encryption) is because
the user has issues with his/her access network. Therefore, *any*
automatic discovery is challenging, to say the least.

So, I disagree with the basic assumption that we *must* do something
to enable a (possibly untrusted) network to override the choices of
the end machine.

> deploy encrypted DNS within the existing network architectures,
> without changing the resolver operator

This would defeat the main point of DoT and DoH. (Which are useful
mostly when you want to use an outside resolver.) I don't think
"without changing the resolver operator" should be in the requirments.

> It would be kind for the IETF to work on that as soon as possible
> and show to the other stakeholders that it cares about all the
> complaints that have been publicly made for the last ~18 months.

I don't think there is a consensus (or even a rough consensus) that
these complaints are sensible.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:30:40 +0100

On Wed, Jan 08, 2020 at 09:34:16PM +0000,
 STARK, BARBARA H <[email-masked]> wrote 
 a message of 29 lines which said:

> applications to replace the resolver I and enterprise network
> operators trust with one that we don't?

To allow people who don't trust the access network to use a distinct
resolver.

> However, I do think it would be useful to see if we can come up with
> a reasonable way to communicate resolver policy. Even if it's just a
> url where you can indicate your privacy preferences when using that
> resolver.

Communicate in which direction? User to resolver ("I want this") or
the opposite way ("I provide that")?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2020 08:33:44 -0800

> "without changing the resolver operator" should be in the requirments.

DoT is useful for opportunistic security.  An automatic way of deploying it with ad-hoc trust is better than no way to deploy it with ad-hoc trust, /as long as that mechanism doesn’t override a verifiable trust relationship if one has been configured./

The reason that we are having a controversy here is that some participants seem to want to be able to override a verifiably trusted configuration and replace it with an ad-hoc (unverifiable) trusted configuration.  Of course no major vendor is going to implement this, but if we were to write a standard that said to do this, I’m sure that a few naive implementors here and there would implement it, to everybody’s sorrow.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:34:51 +0100

On Thu, Jan 09, 2020 at 04:44:11PM +0000,
 Livingood, Jason <[email-masked]> wrote 
 a message of 11 lines which said:

> [JL] Perhaps we can simply solve the problem of how to provide a
> standards-based mechanism to communicate structured data to a client
> about things such as how a resolver operates (e.g. DNSSEC
> validating, DoH URL of X, DOT FQDN of Y, whatever). How the app will
> choose to use that information and make a selection decision seems
> up to the app/OS.

That's tempting (although I suspect there will be some pressures to
force applications to follow blindly these signals from the access
network, thus depriving the end user of a real choice, but I digress.)

But isn't it already done in the PvD project?
https://datatracker.ietf.org/doc/draft-ietf-intarea-provisioning-domains/

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:38:55 +0100

On Wed, Jan 08, 2020 at 03:47:50PM -0800,
 Glenn Deen <[email-masked]> wrote 
 a message of 650 lines which said:

> there does seem to a tremendous amount of interest in the need for
> Discovery and Selection, as well as a broad and diverse set of
> contributors wanting to work on it, and we have groups actually
> working on building and deploying solutions as well.
> 
> The conclusion is that there is a community of interest,
> contributors, and adopters here, and the work is going to be done
> somehow and somewhere

The fact that people are ready to work on it is not sufficient. People
were ready to work on "visibility" proposals for TLS 1.3 and IETF
(rightly) refused to standardize it.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:44:01 +0100

On Fri, Jan 10, 2020 at 01:01:33AM +0000,
 Andrew Campling <[email-masked]> wrote 
 a message of 128 lines which said:

> > "Endpoints should not depend on the confidentiality or integrity
> > of the carriers. Carriers may choose to provide some level of
> > protection, but this is secondary to the primary responsibility of
> > the end users to protect themselves."
> 
> > RFC 1958

> Therefore, the implication of RFC 1958 that it is better to rely on
> the confidentiality or integrity of endpoints rather than carriers
> is at best questionable and is certainly dated.

It seems to me that the RFC1958 opinion is very fundamental in all the
Internet protocols (compared with, say, traditional telco protocols)
and changing it is not in-scope for this list. I don't think that IETF
would agree to revise this end-to-end principle.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:45:50 +0100

On Fri, Jan 10, 2020 at 08:33:44AM -0800,
 Ted Lemon <[email-masked]> wrote 
 a message of 21 lines which said:

> /as long as that mechanism doesn’t override a verifiable trust
> relationship if one has been configured./

Yes, this is the important thing, and it should be in any charter for
a D&S WG.

> Of course no major vendor is going to implement this,

Canary domain in Firefox?

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Fri, 10 Jan 2020 17:48:43 +0100

On Fri, Jan 10, 2020 at 05:44:01PM +0100,
 Stephane Bortzmeyer <[email-masked]> wrote 
 a message of 24 lines which said:

> It seems to me that the RFC1958 opinion is very fundamental in all
> the Internet protocols (compared with, say, traditional telco
> protocols) and changing it is not in-scope for this list. I don't
> think that IETF would agree to revise this end-to-end principle.

And I forgot to mention RFC 3552, which is probably even more relevant
than RFC 1958. It clearly explains that our threat model is "the
network may be hostile and we cannot rely on it".

---

From: Jim Reid <[email-masked]>
Date: Fri, 10 Jan 2020 17:41:19 +0000

> On 10 Jan 2020, at 16:26, Stephane Bortzmeyer <[email-masked]> wrote:
> 
> at the very basis.

No. IMO the reason there are so many (somewhat off-topic) messaages is because we're no longer discussing the charter proposals. Instead, we're rat-holing on detail, use cases and definitions - the sorts of things that should be getting discussed in a WG. If we had one.

> I don't think that resolver discovery *needs* to be addressed.

Even the question of "how to I find an encrypted DNS resolver for the current network?"?

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 10 Jan 2020 17:52:11 +0000

From: Eric Rescorla <[email-masked]>

<bhs> Any attacker that does that in my home network will be able to compromise all sorts of things, and can mess up address assignment, next hop router, etc. If it does this by advertising in addition to my router, it will also cause a race condition that will make the network behave inconsistently (my testing suggests that whatever device advertises first, wins). Of course, if they do this by compromising my router, then I’ve got even bigger problems. Really what I need is a means for detecting such compromises (so I can remove them), rather than a means to try to plug up every possible threat that malware inside the network presents. And detecting multiple DHCP or RA sources is pretty easy. If the router itself is compromised, this is much harder to detect. Having the router sign its RA or DHCP messages won’t help with that. And if the manner of compromise is simply to change my network’s preferred resolver (e.g., from my ISP to Cloudflare), no amount of DNSSEC or encryption will help. But if they can do that, then maybe they can just compromise my devices directly and replace my apps with compromised versions that ignore my choices. In all cases where security has been “forced” on people (e.g., seat belt laws, government food regulations, airline safety regulations), those doing the forcing have to figure out what level of security is “good enough” without making costs too high. For me, the threat of advertisements in my home network being compromised don’t rise to the level of something I’m willing to incur cost to deal with. Maybe that will change in the future. But the only time my home network DNS has ever been compromised was when a family member downloaded a compromised browser that hijacked DNS directly on the family computer. Nothing we’re talking about will help with that.

TL;DR: Unless we can have a solution that is simple enough to push out to all people without them needing to know or do anything while allowing their home network and devices to work exactly as they expect, we have to consider whether the perceived costs/confusion/annoyance/violation-of-expectations is worth the additional security. I’m not opposed to security. I’m opposed to security that gets in my way – especially when it’s protecting me from something that isn’t prevalent.</bhs>

---

From: Ted Lemon <[email-masked]>
Date: Fri, 10 Jan 2020 10:01:28 -0800

On Jan 10, 2020, at 9:52 AM, STARK, BARBARA H <[email-masked]> wrote:
> Really what I need is a means for detecting such compromises (so I can remove them), 

So e.g. if the DHCP message or RA contains information that’s been provided by the attacker, and you have a pre-configured trust relationship with your local resolver, then the DHCP or RA containing a different configuration could be noticed and flagged, and you’d realize you’d been compromised.

That’s a little different than what I had in mind, but if there’s a way to know what network you are connected to, then that might be useful.   Of course, if you have all that information configured anyway, there’s no need to use anything the DHCP service gives you.

IOW, you could have a table of (network-id, resolver-id, resolver-ip-address) configured on your host, and then you’d just verify that you’re connected to your local network and then talk to the configured resolver for that network.   Or you could have a similar table of (network-id, resolver-id) and get the IP address from DHCP or RA.

The latter is probably easier to manage, but then if your network is attacked, you might get the wrong IP address from DHCP or RA, and then you’d detect that the relationship (network-id, resolver-id) doesn’t hold, because the resolver you got would be the wrong resolver.   At that point you could notify the user.

This is only possible if you have a way to validate resolver-id /and/ network-id.

> TL;DR: Unless we can have a solution that is simple enough to push out to all people without them needing to know or do anything while allowing their home network and devices to work exactly as they expect,

I think we have that.

> we have to consider whether the perceived costs/confusion/annoyance/violation-of-expectations is worth the additional security. I’m not opposed to security. I’m opposed to security that gets in my way – especially when it’s protecting me from something that isn’t prevalent.

What I just described is definitely harder to set up than just having e.g. Mozilla point at 1.1.1.1.  As you say, it might be worthwhile, or might not.   But that’s the calculus.   It’s not going to be the other way around, because that’s less secure and more complicated.

---

From: Paul Wouters <[email-masked]>
Date: Fri, 10 Jan 2020 13:01:49 -0500 (EST)

> Even the question of "how to I find an encrypted DNS resolver for the current network?"?

Yes.

In your own home network, you can configure encrypted DNS to your own
server.

In enterprise networks, whatever DHCP DNS can be retrofitted to do
encrypted DNS. But the gains are minimal, you might as well work on
getting mesh encryption going for ALL traffic in your enterprise.  Or uses
(non-standard) enterprise provissioning methods that can be extended.

In ISP networks, there is very low value in encrypted DNS. If you can't
trust your ISP, you basically cannot trust their encrypted DNS either.
If you can trust your ISP, their network is properly segmented and
secure that basically others cannot snoop DNS traffic. If you don't
trust your ISPs ISP, you cannot trust your ISP (eg cable/DSL resellers,
where your ISP isn't the one running DHCP/RA). And ISPs publishing
their "encrypted DNS policues" that are unverifiable isn't going to
help.

For roaming devices on wifi, you can never trust what you are told and
you are dependend on preconfiguration of known trusted encrypted DNS
resolvers anyway.

Every network must be deemed hostile, unless you manually override it
with your trust.

Paul

---

From: Brian Dickson <[email-masked]>
Date: Fri, 10 Jan 2020 10:28:43 -0800

> the opposite way ("I provide that")?

I think "negotiate" might be a better term than communicate.

I think there is more than one potential end state to such negotiations,
if/when you don't trust the resolver offered by the network.

I think one challenge is to be able to distinguish implicit (or preferably
explicit) rules for network access tied to resolver policy.

I think there are definitely places where that tying is completely
legitimate, i.e. privately operated networks that have guest access, such
as enterprise networks.

The two outcomes I'm thinking of for that distrust situation is, "okay, use
your pre-configured trusted resolver, I'm cool with that", and "Sorry, you
may not join this network."

I recognize that these negotiated states may still be reliant on the
negotiating parties to behave according to the negotiated state, i.e. that
the client doesn't lie about what it says it will do.

The starting point in any discussion on whether that negotiation is
feasible, is whether these two states are acceptable to participants of the
proposed WG.

I'll start by asking those expressing strong opinions regarding trust, such
as you, Stephane. Do you think this is reasonable (not joining as an
outcome, if the client indicates they don't agree)?

(This also pre-supposes some pre-established policy by the client, and some
vagueness of what is meant by "client", e.g. O/S, user, application, or a
combination of those.)

Brian

---

From: Andrew Campling <[email-masked]>
Date: Mon, 13 Jan 2020 09:20:02 +0000

On Fri, Jan 10, 2020 at 17:49,  Stephane Bortzmeyer <[email-masked]> wrote:

> On Fri, Jan 10, 2020 at 05:44:01PM +0100,  Stephane Bortzmeyer <[email-masked]> wrote  a message of 24 lines which said:

>> Internet protocols (compared with, say, traditional telco

> And I forgot to mention RFC 3552, which is probably even more relevant than RFC 1958. It clearly explains that our threat model is "the network may be hostile and we cannot rely on it".

So now we have references to two RFCs, one from 1996 and one from 2003, both of which were written when the internet and web were very different to today.  As posted elsewhere, both of these RFCs pre-date the rise of "surveillance capitalism"; the many privacy breaches by apps (and "smart" devices); and the accelerating consolidation leading to a few corporations dominating large parts of the Internet with the consequent loss of resilience (I note that the Internet Society is currently exploring the impact of consolidation in chapter meetings).  Therefore, the view that it is better to rely on the confidentiality or integrity of endpoints rather than carriers/networks is at best questionable and is certainly dated.

Andrew

---

From: Mirja Kuehlewind <[email-masked]>
Date: Mon, 13 Jan 2020 12:18:21 +0100

I think the underlying idea of Adaptive DNS and the proposed charter is that you maybe want to use more than one resolver depending on the service you are requesting. 

> On 10. Jan 2020, at 19:01, Paul Wouters <[email-masked]> wrote:
>

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 13 Jan 2020 04:50:43 -0800

On Mon, Jan 13, 2020 at 1:20 AM Andrew Campling
<[email-masked]> wrote:

> > On Fri, Jan 10, 2020 at 05:44:01PM +0100,  Stephane Bortzmeyer <
> [email-masked]> wrote  a message of 24 lines which said:
>
> than RFC 1958. It clearly explains that our threat model is "the network
> may be hostile and we cannot rely on it".
>
> So now we have references to two RFCs, one from 1996 and one from 2003,
> both of which were written when the internet and web were very different to
> today.  As posted elsewhere, both of these RFCs pre-date the rise of
> "surveillance capitalism"; the many privacy breaches by apps (and "smart"
> devices); and the accelerating consolidation leading to a few corporations
> dominating large parts of the Internet with the consequent loss of
> resilience (I note that the Internet Society is currently exploring the
> impact of consolidation in chapter meetings).  Therefore, the view that it
> is better to rely on the confidentiality or integrity of endpoints rather
> than carriers/networks is at best questionable and is certainly dated.
>

I think I disagree with your implied argument.There's not much evidence
that the network has done much of anything to ameliorate surveillance
capitalism, as opposed to trying to get into the game itself. However, this
isn't the place to debate the Internet threat model. If you want to do
that, I would suggest you join the IAB's new "model-t' effort.

-Ekr

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Mon, 13 Jan 2020 14:40:59 +0100

On Fri, Jan 10, 2020 at 10:28:43AM -0800,
 Brian Dickson <[email-masked]> wrote 

> I think "negotiate" might be a better term than communicate.
...
> explicit) rules for network access tied to resolver policy.
...
> outcome, if the client indicates they don't agree)?

I think your ideas are interesting, and it would be cool if it worked
but I'm skeptical. First, some people don't want to negotiate (you
typically do not discuss the policies with your Internet Access
Provider: it is "take it or leave it"). Second, protocols with
negotiation are hard to get right, specially security-wise. There will
be risks of downgrade attacks. (A good example is the canary domain,
which allows a network to easily disable security on the client.)

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jan 2020 08:59:23 -0500

Of course, in addition, this whole debate is ultimately about an RFC written in 1987, so perhaps you should just stop using DNS entirely if this is how you evaluate the worth of RFCs?

> On Jan 13, 2020, at 04:20, Andrew Campling <[email-masked]> wrote:
> 
> So now we have references to two RFCs, one from 1996 and one from 2003, both of which were written when the internet and web were very different to today.

---

From: Andrew Campling <[email-masked]>
Date: Mon, 13 Jan 2020 14:38:56 +0000

> On Jan 13, 2020, at 13:59, Ted Lemon <[email-masked]> wrote:
> 
> Of course, in addition, this whole debate is ultimately about an RFC written in 1987, so 
> perhaps you should just stop using DNS entirely if this is how you evaluate the worth of RFCs?

I note that RFC 1034 includes references to updates from 18 subsequent RFCs; by contrast, RFC 1958 lists one and RFC 3552 lists none.  I think it reasonable to suggest that, for example, a BCP covering security considerations may need updating after 16 or so years - note this is not to suggest that the content is not valuable, simply that it might not fully reflect the current situation.  However, as one of its authors has suggested, this discussion can be continued under the auspices of the IAB's "model-t' list.

Andrew

---

From: Ted Lemon <[email-masked]>
Date: Mon, 13 Jan 2020 09:51:11 -0500

There have been a lot of updates to the IETF’s policies on privacy in later RFCs. They just don’t happen to support your position. 

> On Jan 13, 2020, at 09:39, Andrew Campling <[email-masked]> wrote:
> 
> 
>>

---

From: Kenji Baheux <[email-masked]>
Date: Wed, 15 Jan 2020 02:08:25 +0900

> network, thus depriving the end user of a real choice, but I digress.)

What sort of pressures are you talking about?