Re: [dns-privacy] New Version Notification for draft-peterson-dot-dhcp-00.txt
On Tue, May 7, 2019, at 04:24, Dan Wing wrote: > On May 5, 2019, at 9:25 PM, Martin Thomson 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 dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
Re: [dns-privacy] New Version Notification for draft-peterson-dot-dhcp-00.txt
On May 5, 2019, at 9:25 PM, Martin Thomson 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). https://tools.ietf.org/html/draft-reddy-dprive-bootstrap-dns-server-02#section-3 Earlier versions of that same I-D did different things; we have reduced scope considerably. -d ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
[dns-privacy] dprive - Update to a Meeting Session Request for IETF 105
An update to a meeting session request has just been submitted by Brian Haberman, a Chair of the dprive working group. - Working Group Name: DNS PRIVate Exchange Area Name: Internet Area Session Requester: Brian Haberman Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 120 Conflicts to Avoid: First Priority: dnssd doh dnsop lamps Second Priority: acme saag homenet People who must be present: Brian Haberman Eric Vyncke Tim Wicinski Resources Requested: Special Requests: - ___ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
