On Thu, Nov 13, 2014 at 9:41 AM, Paul Wouters <p...@nohats.ca> wrote: > On Thu, 13 Nov 2014, Hugo Connery wrote: > >> 2. Trust between clients (stubs) and recursive resolvers >> >> Whether the communication to the recursive resolver is encrypted or not >> the >> resolver itself knows all queries (data and metadata). There is an >> implicit >> trust relationship between the client and recursive resolver. >> >> This is a political rather than technical issue (unless some PIR style >> solution is pursued) and is probably outside the scope of DPRIVE. > > > I would like to see that any solution would actually tackle this > problem. A more and more common scenario is to only use local DNS for > bootstrap and then rely on another non-local DNS server outside the > control of the local network. > > For example, if Google DNS could advertise a "resolver public key" than > I could use the hotspot DNS to pay/click ok, and then only send > encrypted DNS to Google so the local network cannot see any of it.
Actually, we probably want to have a mechanism for using encryption on DHCP as well. It would be a way to close the WiFi evil twin issue. I don't think this area actually has a bearing on choices between proposals as we are all using TLS at the front end. The only divergence is whether to use it on the back end or not. So lets say we are in Panera. The coffee shop is a national chain that wants to assure customers they are going to the real panera. They also want to do a splash screen for T&C. Right now the mechanisms for implementing that are folklore which is bad. I see the following approaches: 1) Advertise a DNS name, IP address and URI in a DHCP record. This is the simplest, the hotspot only wants to provide the data for the very limited purpose of T&C. Making it part of DHCP allows the platform to present the T&C dialog etc. 2) DHCP record for DPRIV DNS This would be for a promiscuous DNS service that can be used for the T&C transaction and then ignored thereafter. Problem with this is that it tends to be flaky, it is not clear where the T&C bit starts and ends. 3) Regular DHCP with upgrade in the DNS transaction. Some EDNS option to tell the client that DPRIV is available... Caveats: 1) Panera is not going to worry about the cost of an EV cert to establish their WiFi service is genuine. For a small coffee shop or non commercial WiFi this would not be an acceptable cost. Nor would the CA service really add much to a service provider with a single site. For the home user, getting an EV cert is definitely out of the question. 2) Panera is doing DNS interception because they don't want people surfing to sites showing pictures of nakid people in their cafe. Hard to see how to reconcile this with censorship bypass because its incompatible. The coffee shop would still have the option of filtering on IP addresses though. > The same scenario would apply to ISPs whose nameservers people would > like to not trust or use. > >> 3. Recursive to Authoritative >> >> Without the possibility of encrypting this stage, the client becomes >> anonymous >> within the community that is using the recursive resolver. Encrypting >> this step >> may be "too much" for now (and it will incur challenges for auth >> resolvers). >> >> If omitted, I hope that the community will re-visit the issue. > > > Agreed. This problem is very hard because it is a DOS against > authoritative servers. > > Paul > > > _______________________________________________ > dns-privacy mailing list > dns-privacy@ietf.org > https://www.ietf.org/mailman/listinfo/dns-privacy _______________________________________________ dns-privacy mailing list dns-privacy@ietf.org https://www.ietf.org/mailman/listinfo/dns-privacy
