On Sat, Aug 30, 2014 at 12:56 AM, John Heidemann <[email protected]> wrote: > On Wed, 27 Aug 2014 12:46:41 -0700, Wes Hardaker wrote: >>Carsten Strotmann <[email protected]> writes:
>>But then, stepping back, you have to ask yourself: what's the likely >>threat model of everyone in 100 feet trying to attack you? If we really >>... >> >>But what's the solution? How do we authenticate that resolver? PKIX >>won't help us, as there is no name. DNSSEC won't help us, as half the >>time you're behind a nat so the reverse tree can't be used [ipv6 >>actually might help here]. Leap of faith is probably better than >>nothing if you frequent that coffee shop. I don't think secure dhcp has >>gotten that far, but I'm admittedly out of touch. >> >>We simply keep moving this chicken/egg problem of secure bootstrapping >>from one protocol to the next. It's like one egg that keeps changing >>chickens. > > I want to take a step back to consider a different case. > > The complaint here is that it is tough to authenticate some arbitrary > resolver handed to you from DHCP because of person-in-the-middle. Yes, > that's a hard problem. > > "Doctor, it hurts when I do this." "Don't *do* that." Exactly. Step one to better DNS security is NEVER EVER USE THE DHCP DNS SERVER The only exception being finding a path to your intended DNS server. People keep trying to fix DNS security by applying the security that fits a broken 30 year old model designed at a time when absolutely nobody knew what they were doing. > If you aren't willing to trust a resolver from DHCP, one could use a > public DNS resolver, acquire its certificate out-of-band, and check it. > I.e., do certificate pinning on the TLS certificate you plan to use for > DNS. Hang on, the machine could do that but lets keep the user out of this please? Any time people suggest complicated configuration then its a protocol nobody will ever use. The machine can do those steps but not the human. It has to be frictionless or it will never get used. > I'm told there are IP addresses of a public resolver spraypainted on > walls in Turkey you could try. (If that or some other provider > supported TLS for DNS.) Well the spray-painted one got blocked so we need to do a little more than that. In my Private-DNS scheme the user binds their account to a security provider that potentially provides a raft of security services. This is a one time event per user until they change providers. They then bind each of their machines to their account using a simple, easy to use mechanism. This is not doing TLS pinning, but thats because I didn't find TLS provides much leverage except for initial configuration. _______________________________________________ dns-privacy mailing list [email protected] https://www.ietf.org/mailman/listinfo/dns-privacy
