On Mon, Apr 13, 2015 at 4:13 PM, Daniel Kahn Gillmor <[email protected]> wrote: > On Thu 2015-04-09 10:36:17 -0400, Phillip Hallam-Baker wrote: >> As I see it, there are two sub-problems: >> >> 1) How does a client discover and establish a binding to a DPRIV service? >> 2) What transport/sessions(s) are supported for queries? >> >> Before answering either, I think it is pretty clear that at some point >> in the future, SPUD will be the logical choice for transport/session. >> It is also clear that we should not build research on research. >> >> So the way forward as I see it should be that our answer to (1) should >> support some mechanism for advertising alternative transports so we >> can use TLS for now and make use of SPUD if and when it matures. > > I'm not convinced that SPUD is the long-term way forward, fwiw. But > there was enough discord between the different proposals within DPRIVE > that "use TLS for now" seems like it would be a great consensus to come > to. I hope we reach it. > > I'd like to make sure we have a clear sense of how to do this securely > and efficiently independently of wrangling about this next part: > >> The hard part of the problem is all in problem 1. I designed, >> implemented and wrote the draft for the transport/session part in a >> day. It isn't a difficult problem (if you are only solving DNS, SPUD >> is a lot harder). The hard question is how to discover and establish a >> binding to the DNS service before you have DNS. > > I don't think this is quite as hard as you're making it out to be. > We're going from: > > * for each resolver, get: > - an IP address > > to: > > * for each resolver, get: > - an IP address > - a privacy-preserving transport mechanism > - a trust anchor > > Current discovery mechanisms are: > > * Manual configuration > * DHCP > > i think most people consider DHCP configuration to be at best minimally > useful for DPRIVE -- it leaves you vulnerable at network connection > time, but then protects you against subsequent attacks. *shrug*
<no hats> Well, all depends on what your threat model is / who you are protecting against. My home router also provides wireless, protected with WPA and client isolation. My Internet access is a 4.5 mile WiFi link (authenticated using PPPoE) to an ISP that I don't really trust. Their DNS performance is horrendous (possibly because last time I checked they were running BIND 9.3.2 as an open recursive, and were often used in reflection attacks), and so I've configured my CPE to hand out 8.8.8.8, 8.8.4.4 via DHCP. I'm not really concerned about someone who is able to hop on my home wifi providing fake DNS servers over DHCP - I *am* concerned about all of my DNS packets flying through the air unencrypted from my house to the ISP, and on the 12 hops from my ISP to 8.8.8.8. I have another location where I connect to Comcast (who I trust way more than my regular ISP!). Comcast has provided the CPE in this case and it hands out Comcast DNS servers via DHCP. I'd be happier accepting DPRIVE info via DHCP from my CPE than simply shipping queries across buried cables in the clear. What I'd kind of assumed was that machines would be configured with a specific DPRIVE server to talk to (and not blindly trust DHCP), but I think that in many / most cases trusting DHCP is better than nothing... W > > Perhaps DHCP could be seen as a mechanism to propose available choices > for manual configuration? > > At any rate, i think we shouldn't block transport mechanism work on > discovery mechanism work. > > --dkg > > _______________________________________________ > dns-privacy mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dns-privacy -- I don't think the execution is relevant when it was obviously a bad idea in the first place. This is like putting rabid weasels in your pants, and later expressing regret at having chosen those particular rabid weasels and that pair of pants. ---maf _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
