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

[Wes Hardaker <[e-mail]>]

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
are worried about protecting people at starbucks, what's the likelyhood
of 2 people in starbucks trying to sniff your private dns lookups at the
same time?  Probably super-duper low.  So, are we really protecting you
at all if the one bad person in the coffee shop is able to convince you
it's the local resolver?  IE, if we blindly assume that whatever key we
get is ok then we're buying ourselves very minimal protection against
the few opponents within spitting distance of a wireless box.  Likely
there will be just one, and it'll likely succeed in defeating your
encryption.

Now, in larger venues where are there are potentially lots and lots of
people that are targeting an environment for sniffing, say at an IETF
convention where we're very good at overwhelming infrastructure, then
the likelyhood of having multiple malicious eves goes way up and maybe
we've achieved a bit of protection by transmitting our dns request data
to just one advocacy instead of them all.


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.

-- 
Wes Hardaker
Parsons