On Tue, May 7, 2019, at 04:24, Dan Wing wrote: > On May 5, 2019, at 9:25 PM, Martin Thomson <[email protected]> wrote: > > No mention here of how you get the name for certificate validation still. > > That's still important. > > We wrote a procedure where an endpoint can see if the local network's > DNS servers are already on the endpoint's trust list (e.g., you trust > your ISP's DoH server, visit a friend using that same ISP so you want > to trust that same configuration at your friend's house). When joining > a network where you don't trust that network's DNS servers, the user is > asked if they want to trust that network's DNS servers for DoH. We > also added some policy communication so the user can determine if they > like the DNS server's policies (e.g., selling browsing history, > filtering malware, etc.). With the policy information, the endpoint > could avoid bugging the user if that network's DoH policies aren't at > all aligned with the user's desires (e.g., user always wants malware > filtering or wants parental filtering).
Hi Dan, I wasn't talking about trust, I was simply talking about ensuring that the server you are talking to the one is the one the network intends. But how you might automate some of the process of "trust" is not something I think we should be talking about until we know what "trust" looks like in more detail. There is probably a place for building whitelists, but it's not clear that the DoH server someone "trusts" at home is something they want to "trust" when they are someplace else. --Martin _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
