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

[John Heidemann <[e-mail]>]

On Wed, 27 Aug 2014 12:46:41 -0700, Wes Hardaker wrote: 
>Carsten Strotmann <[e-mail]> writes:
>
>>> Ok then I am an attacker, since you cannot authenticate me, I sign the
>>> data myself. This has data integrity. But it is the modified data and
>>> not what you expected to receive...
>>
>> How can you sign DNSSEC data without being in the posession of the
>> private signing key(s) all the way to the root?
>>
>> DNSSEC adds data integrity, and with one or more trust-anchors in the
>> resolver the client is able to validate the data, no matter which way
>> the data took.
>
>So, there is some confusion here I think so we need to be clear about a
>few things.  We're talking about privacy, and in this context
>stub-to-resolver entirely.  There are two forms of
>integrity/authentication going on and they need to be clearly separated
>but I keep seeing them being thrown together.
>
>DNSSEC absolutely helps you ensure that the end data you got is "good"
>from the notion of the publisher.
>
>But it doesn't help you to identify the public key of the resolver
>you're using to query for those results.  So it doesn't help you ensure
>you're encrypting your packets to the right destination.  And DNSSEC may
>ensure you have the right data, but it doesn't help you determine if you
>really did get it in a way that no one else but you, the coffee shop
>owner, and the final destination could see.  And this is the important
>bit: in the context of the discussion, we are only talking about
>verifying the public key of the resolver in order to implement privacy;
>Clearly DNSSEC has solved authenticating the data itself and that's not
>in question.  I think most people understand this difference (I hope).
>
>
>But here's the thing that is keeping me awake at nights in this topic:
>we keep saying that "un-authenticated encryption is better than no
>encryption".  And I do generally think this is true.  At least you're
>only transmitting your data to one potentially bad person (the one
>you've done a key negotiation with) rather than letting anyone with 100
>feet view the data.
>
>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."

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.

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.)

   -John