Re: [DNSOP] Draft for dynamic discovery of secure resolvers

[Ted Lemon <[e-mail]>]

That may indeed be correct.   If it is correct, then the next step would be
to try to design a trust model that we can agree on, that addresses both
use cases rather than requiring us to choose one or the other.   E.g., we
could say that if you are Chinese, then your device is required to trust
the GFWoC; if you are not, and you never go to China, your device should
not trust it.  If you aren't Chinese but you travel to China, you should
probably be asked to make a policy decision.   And now when the network
operator hands you a DoH or DoT server, you should be able to validate what
you've been handed.   Am I willing to trust Paul Vixie's network?   Then I
can configure that, and then when I am on Paul's network and his network
hands me a pointer to his DoH server, I'll use that.   When I'm not on his
network, I won't.   Right?

On Sun, Aug 19, 2018 at 2:46 PM, Marek Vavruša <[e-mail]>
wrote:

> Interesting. This approach is similar to the lists curated by Frank
> and people from dnscrypt-proxy: https://dnscrypt.info/public-servers
>
> Assuming that separating protocol change from trust model change is a
> no-go, then the trust would need to go both ways - the network
> operator would need to push the list of resolvers that she considers
> trusted, and the client would crosscheck that list to its provisioned
> configuration (or list downloaded from a public service such as this
> etc.). This is conceptually similar to NPN/ALPN.
>
> Marek
>
> On Sun, Aug 19, 2018 at 11:35 AM, Tom Pusateri <[e-mail]> wrote:
> >
> >
> > On Aug 19, 2018, at 9:29 AM, Livingood, Jason <
> [e-mail]>
> > wrote:
> >
> > On 8/18/18, 7:03 PM, "DNSOP on behalf of bert hubert"
> > <[e-mail] on behalf of [e-mail]> wrote:
> >    Especially when such a move will incidentally kill intranets, VPNs,
> split
> >    horizon, DNS monitoring & DNS malware detecion and blocking.
> >
> > It seems to me that the underlying protocol is separable from the
> > operational implementation, and the latter case is likely where most of
> the
> > concerns lie. Thus, the issue is likely less DoH itself but rather how
> it is
> > likely to be deployed.
> >
> > I am considering starting work on a draft along the lines of 'potential
> > impacts of DoH deployment' to try to document some of this, if for
> nothing
> > else than to organize my own thinking on the matter. This is because I
> also
> > share concern, given the apparent deployment model, around what may
> break in
> > enterprise networks, malware detection & remediation, walled garden
> portals
> > during service provisioning, parental controls, and the impacts of
> > eliminating other local policies. The CDN-to-CDN competition case is an
> > interesting one as well, with respect to passing EDNS client subnet or
> not.
> >
> > JL
> >
> >
> > In the DRIU BOF, I mentioned establishing a reputation service for public
> > DNS resolvers. With a JSON interface, this could lead to users conveying
> > some trust of a public service or more likely, the inverse of trust for
> > operating systems or stub resolvers to whitelist/blacklist public DNS
> > resolvers.
> >
> > I tried to summarize it here:
> >
> > https://dnsdisco.com/reputation-post.html
> >
> > Or you could go listen to the proceedings of the DRIU BOF.
> >
> > Thanks,
> > Tom
> >
> >
>