Subject: [Add] Foundational questions on draft-box-add-requirements

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Sep 2020 17:22:17 +0000

Greetings. In reading the new draft, I have two questions based on the wording in Section 2. I hope this helps focus the discussion of this draft.

The terminology section defines an "associated resolver" as
   A resolver operated by the same entity that
   provides the resolver the client started with.

1) Shouldn't "the resolver" be "the unencrypted resolver"? Or is the intention for the document to cover discovering alternatives to a currently-selected encrypted resolver?

2) Why must the associated resolver be operated by the same entity? If an ISP offers only unencrypted resolvers, but is happy to point its customers to resolvers operated by someone else (such as a public resolver) for when they want encryption, why should this document prohibit that?

--Paul Hoffman

---

From: Eric Orth <[email-masked]>
Date: Tue, 8 Sep 2020 14:00:24 -0400

On Tue, Sep 8, 2020 at 1:22 PM Paul Hoffman <[email-masked]> wrote:

> 2) Why must the associated resolver be operated by the same entity? If an
> ISP offers only unencrypted resolvers, but is happy to point its customers
> to resolvers operated by someone else (such as a public resolver) for when
> they want encryption, why should this document prohibit that?
>

I think many clients are mostly interested in a "same-provider" upgrade,
but I think you make a good point that maybe the draft shouldn't be
mandating anything around that.  It's encroaching into policy.

Maybe we just need a flag to specify whether or not a listed resolver is
run by the same entity and let clients make decisions about it.  Would that
be useful without a mechanism to enforce truthfulness of the flag? Maybe
fine since you're already placing plenty of trust in the initial resolver.

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Sep 2020 11:03:27 -0700

> fine since you're already placing plenty of trust in the initial resolver.

I would say technically you're placing trust in the mechanism that told you
about that resolver. Consider the case where I have configured my resolver
(via resolv.conf or whatever) to be 1.1.1.1. With a mechanism such as the
one that MSFT (and I believe Chrome) uses, I would automatically be
upgraded to Do[HT] regardless of the configuration of my local network.
However, if I were to ask the resolver who operated it over Do53 that would
require me to trust the local network, no?

-Ekr

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

---

From: Eric Orth <[email-masked]>
Date: Tue, 8 Sep 2020 14:27:04 -0400

On Tue, Sep 8, 2020 at 2:04 PM Eric Rescorla <[email-masked]> wrote:

>>> 2) Why must the associated resolver be operated by the same entity? If
>>> an ISP offers only unencrypted resolvers, but is happy to point its
>>> customers to resolvers operated by someone else (such as a public resolver)
>>> for when they want encryption, why should this document prohibit that?
>>>
>>
> I would say technically you're placing trust in the mechanism that told
> you about that resolver. Consider the case where I have configured my
> resolver (via resolv.conf or whatever) to be 1.1.1.1. With a mechanism such
> as the one that MSFT (and I believe Chrome) uses, I would automatically be

Correct for Chrome.  If 1.1.1.1 is configured, DoH will be attempted to
https://chrome.cloudflare-dns.com/dns-query.

> However, if I were to ask the resolver who operated it over Do53 that
> would require me to trust the local network, no?
>

Maybe you could ask the target DoH server if it has the same operator as
the original Do53 address.  Has the advantage that the DoH server is at
least an authenticated connection.  But that's not giving much protection
if you didn't have a mechanism to prevent a network attacker from just
sending you to an attacker-controlled DoH server to start with.

---

From: Tommy Jensen <[email-masked]>
Date: Tue, 8 Sep 2020 18:52:05 +0000

> With a mechanism such as the one that MSFT (and I believe Chrome) uses, I would automatically be upgraded to Do[HT] regardless of the configuration of my local network

Correct for Windows as well. Network recommended servers are and have always been a default recommendation overridden by user/admin provided configuration.

So circling back to the original question Paul posed: if a user/admin told me through any UX (UI, script, policy, default to network recommendation, etc.) to use Server A, then Server A recommends Server B, I want to ensure Server B is owned by the same entity as Server A or hard fail.

However, I do think a network has the right to recommend a third-party server if it so chooses (because it's a recommendation and not a network required DNS server; that's a separate problem).

A network could offer a local, classic DNS server as well as a public DoH server over DHCP or RA. I won't care as a client that they aren't related. I would however care if the local server tried to recommend the DoH server and ownership couldn't be proved. One day, if we have authenticated network recommendations, this difference will become important.

Thanks,
Tommy

================================================

The latest in Windows Internet Protocols:

  Native gRPC support: https://aka.ms/grpcblogpost

  DNS over HTTPS: https://aka.ms/dohblogpost

________________________________
From: Add <[email-masked]> on behalf of Eric Orth <ericorth=[email-masked]>
Sent: Tuesday, September 8, 2020 11:27 AM
To: Eric Rescorla <[email-masked]>
Cc: Paul Hoffman <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: [EXTERNAL] Re: [Add] Foundational questions on draft-box-add-requirements

On Tue, Sep 8, 2020 at 2:04 PM Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Sep 8, 2020 at 11:00 AM Eric Orth <ericorth=[email-masked]<mailto:[email-masked]>> wrote:

On Tue, Sep 8, 2020 at 1:22 PM Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:
2) Why must the associated resolver be operated by the same entity? If an ISP offers only unencrypted resolvers, but is happy to point its customers to resolvers operated by someone else (such as a public resolver) for when they want encryption, why should this document prohibit that?

I think many clients are mostly interested in a "same-provider" upgrade, but I think you make a good point that maybe the draft shouldn't be mandating anything around that.  It's encroaching into policy.

Maybe we just need a flag to specify whether or not a listed resolver is run by the same entity and let clients make decisions about it.  Would that be useful without a mechanism to enforce truthfulness of the flag? Maybe fine since you're already placing plenty of trust in the initial resolver.

I would say technically you're placing trust in the mechanism that told you about that resolver. Consider the case where I have configured my resolver (via resolv.conf or whatever) to be 1.1.1.1. With a mechanism such as the one that MSFT (and I believe Chrome) uses, I would automatically be upgraded to Do[HT] regardless of the configuration of my local network.

Correct for Chrome.  If 1.1.1.1 is configured, DoH will be attempted to https://chrome.cloudflare-dns.com/dns-query<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fchrome.cloudflare-dns.com%2Fdns-query&data=02%7C01%7CJensen.Thomas%40microsoft.com%7Cfa434cbf869f42a1276008d85424d78e%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637351864928466841&sdata=ixOkMpXtV%2FcDt%2FxtvHrngww2OHPI6RtN5l%2BrnCH1134%3D&reserved=0>.

However, if I were to ask the resolver who operated it over Do53 that would require me to trust the local network, no?

Maybe you could ask the target DoH server if it has the same operator as the original Do53 address.  Has the advantage that the DoH server is at least an authenticated connection.  But that's not giving much protection if you didn't have a mechanism to prevent a network attacker from just sending you to an attacker-controlled DoH server to start with.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Sep 2020 19:35:32 +0000

> On Sep 8, 2020, at 11:52 AM, Tommy Jensen <Jensen.Thomas=[email-masked]> wrot

How does the client ensure ownership? This seems to be a legal question, not a technical one.

--Paul Hoffman

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 8 Sep 2020 12:43:55 -0700

On Tue, Sep 8, 2020 at 12:35 PM Paul Hoffman <[email-masked]> wrote:

> > So circling back to the original question Paul posed: if a user/admin
> told me through any UX (UI, script, policy, default to network
> recommendation, etc.) to use Server A, then Server A recommends Server B, I
> want to ensure Server B is owned by the same entity as Server A or hard
> fail.
>

There certainly is a legal definition of "ownership" but we also have a
fair amount of experience with technical enforcement of "this is the same
entity", in particular in the Web context where we have the concept of
"origin". As a concrete example, if A and B had a WebPKI certificate with
the same domain name, that would demonstrate a commonality of operation
(though perhaps not actual ownership)

-Ekr

---

From: Jim Reid <[email-masked]>
Date: Tue, 8 Sep 2020 21:07:46 +0100

> On 8 Sep 2020, at 20:43, Eric Rescorla <[email-masked]> wrote:
> 
> As a concrete example, if A and B had a WebPKI certificate with the same domain name, that would demonstrate a commonality of operation (though perhaps not actual ownership)

FWIW I think it would be wiser for the WG to focus on this notion of commonality of operation and avoid shed-painting about ownership. The latter will probably be a rat-hole that’s impossible to escape from. Besides, ownership is going to be a nebulous concept in some settings. For instance, in enterprise networks or small ISPs who outsource DNS service to a third party. The same goes for CPE that’s been provisioned with a resolver for some home network by the ISP who supplied the box.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Sep 2020 16:20:01 -0400

Paul Hoffman <[email-masked]> wrote:
    > 1) Shouldn't "the resolver" be "the unencrypted resolver"? Or is the
    > intention for the document to cover discovering alternatives to a
    > currently-selected encrypted resolver?

It seems to me that different resolvers might offer different feature sets
particularly as related to filtering.
(Even on the same system, different users might want different things)

--
Michael Richardson <[email-masked]>   . o O ( IPv6 IøT consulting )
           Sandelman Software Works Inc, Ottawa and Worldwide

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Sep 2020 21:18:25 +0000

On Sep 8, 2020, at 1:07 PM, Jim Reid <[email-masked]> wrote:
> FWIW I think it would be wiser for the WG to focus on this notion of commonality of operation and avoid shed-painting about ownership.

If the WG wants to limit the things go which an operator can refer to only things it operates, that's fine; it's a restriction we have not seen documented so far, so I wanted to be sure it was conscious.

---

From: Paul Hoffman <[email-masked]>
Date: Tue, 8 Sep 2020 21:20:48 +0000

> (Even on the same system, different users might want different things)

Sure, but that doesn't answer the question. If the client starts with an encrypted resolver, can it expect these protocols to support it discovering other resolvers associated with the encrypted resolver?

--Paul Hoffman

---

From: Jim Reid <[email-masked]>
Date: Tue, 8 Sep 2020 23:16:56 +0100

> If the WG wants to limit the things go which an operator can refer to only things it operates, that's fine; it's a restriction we have not seen documented so far, so I wanted to be sure it was cons…

I wasn't suggesting that Paul. I think/hope the WG should consider how resolver services are operated/provided and not bother too much about the semantics of ownership/control of those services. I hope that clarifies things. Or maybe it adds to the confusion?

---

From: Michael Richardson <[email-masked]>
Date: Tue, 08 Sep 2020 18:17:50 -0400

Paul Hoffman <[email-masked]> wrote:
    >> It seems to me that different resolvers might offer different feature
    >> sets particularly as related to filtering.  (Even on the same system,
    >> different users might want different things)

    > Sure, but that doesn't answer the question. If the client starts with
    > an encrypted resolver, can it expect these protocols to support it
    > discovering other resolvers associated with the encrypted resolver?

Sorry.  I guess I could have answered the question more clearly.

Yes, I think that it's reasonable for encrypted resolvers to know about
other encrypted resolvers.

The plain-text/insecure resolvers are being given mechanisms to find the
encrypted one(s), and a simple implementation just populates that information
everywhere.

---

From: Tommy Jensen <[email-masked]>
Date: Wed, 9 Sep 2020 19:54:49 +0000

Indeed, this is what I meant.

Thanks,
Tommy Jensen
================================================
How can you secure your DNS queries? https://aka.ms/dohblogpost

________________________________
From: Eric Rescorla <[email-masked]>
Sent: Tuesday, September 8, 2020 12:43 PM
To: Paul Hoffman <[email-masked]>
Cc: Tommy Jensen <[email-masked]>; ADD Mailing list <[email-masked]>
Subject: Re: [Add] [Ext] [EXTERNAL] Re: Foundational questions on draft-box-add-requirements

On Tue, Sep 8, 2020 at 12:35 PM Paul Hoffman <[email-masked]<mailto:[email-masked]>> wrote:

> On Sep 8, 2020, at 11:52 AM, Tommy Jensen <Jensen.Thomas=[email-masked]<mailto:[email-masked]>> wrot

There certainly is a legal definition of "ownership" but we also have a fair amount of experience with technical enforcement of "this is the same entity", in particular in the Web context where we have the concept of "origin". As a concrete example, if A and B had a WebPKI certificate with the same domain name, that would demonstrate a commonality of operation (though perhaps not actual ownership)

-Ekr