Re: [dns-privacy] New draft on encrypting the stub-to-resolver link: draft-hoffman-dns-tls-stub-00.txt

[Phillip Hallam-Baker <[e-mail]>]

On Sat, Aug 30, 2014 at 12:56 AM, John Heidemann <[e-mail]> wrote:
> On Wed, 27 Aug 2014 12:46:41 -0700, Wes Hardaker wrote:
>>Carsten Strotmann <[e-mail]> 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.