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

[Tommy Jensen <[e-mail]>]

> 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 <[e-mail]> on behalf of Eric Orth <ericorth=[e-mail]>
Sent: Tuesday, September 8, 2020 11:27 AM
To: Eric Rescorla <[e-mail]>
Cc: Paul Hoffman <[e-mail]>; ADD Mailing list <[e-mail]>
Subject: [EXTERNAL] Re: [Add] Foundational questions on draft-box-add-requirements



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


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

On Tue, Sep 8, 2020 at 1:22 PM Paul Hoffman <[e-mail]<mailto:[e-mail]>> 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.