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

[Mark Andrews <[e-mail]>]

In message <[e-mail]>, Wes Hardaker writes:
> 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).

Actually DNSSEC could give you the key of the resolver securely
provided it has a public address.  Publish a KEY record signed in
the DNS under in-addr.arpa or ip6.arpa.  If need to we define flag
bits to say it is for this purpose.  For private addresses you need
to have a trust anchor for the private part of the reverse tree or
use leap of faith.

This also works for any authoritative server.

Alternatively we could allocate a new type to hold the key material.

You can't hide that you are talking to a resolver so there is no
need to encrypt the lookups for the KEY, DNSKEY, DS lookups required
to validate the KEY.

> 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
> 
> _______________________________________________
> dns-privacy mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dns-privacy
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: [phone]                 INTERNET: [e-mail]