Subject: Re: [dns-privacy] Padding

From: Hugo Maxwell Connery <[email-masked]>
Date: Thu, 23 Oct 2014 17:29:45 +0000

I dont like to be negative, but the padding solution
seems to me to either cause potentially undue harm
and or wasted effort, and/or do very little to address
confidentiality ...

Assume that stub to iterative resolver communications
are confidential and that iterative to authoritative
communications remain unchanged (clear text).

Each cache miss, in which the interative resolver needs
to query authoritative resolvers to answer the query,
exposes the fact that some member of the community is
interested in the cache miss domain.

If the iterative resolver generates additional 'cache miss'
queries in which it attempts to obscure the 'real' ones
this would seem to hide real ones amongst the 'fake' ones.

Unfortunately, this does not really help.  Yes, it obscures
for cases where the watcher is trying to analyse patterns
in all queries, but does nothing when all they are interested
in is finding specific queries.  You can add all the padding
you like, but the query to intersting.tld will still show up.

As the iterative resolver needs some way to decide
how to choose what its 'fake' cache miss queries will be,
it could choose domains that some watcher is interested
in (interesting.tld) when that query has not been requested
by any client.  Thus, the watcher may become interested in the
client community when that 'interest' is misled.  Indeed,
one might end up being charged with 'misleading law enforcement'
or some equivalent.

What 'interesting.tld' is for one watcher agency may be
benign for the next, and vice versa.  Thus, the iterative
resolver needs to understand politics in order to not
induce undue surveillance upon its clients.

To solve this, the iterative resolver must only use
'fake' queries which correspond to real queries which
have an expired TTL.  Thus, the iterative resolver's
ability to generate fake queries is regulated by the
TTLs of the domains which it has queried (race to the
bottom?), and all it is doing is obscuring the *frequency*
of the cache miss queries.

Or one could have a known set of benign domains which
are used for padding.  In which case the watchers just
filter this out and you are back to where you started.

Essentially, all of the above calls for a Threat Model in these
discussions.

Regards,
--
Hugo Connery, Head of IT, DTU Environment, http://www.env.dtu.dk
GPG: https://keys.env.dtu.dk/hugo-connery/email/valid-to-2015-04-15/Hugo-Connery.public-key.txt
________________________________________
From: dns-privacy [[email-masked]] on behalf of Stephen Farrell [[email-masked]]
Sent: Thursday, 23 October 2014 14:08
To: [email-masked]
Subject: [dns-privacy] Padding (Was: Re: Confidentiality from Iterative to Authoritative resolvers.)

I think the answer to this question may be a simple "no, don't"
but it if were not, it might be something that'd improve privacy
for both stub<->recursive and recursive<->authoritative without
changes to the DNS, but probably requiring some new protocol to
run alongside. Anyway...

On 23/10/14 12:36, Hugo Maxwell Connery wrote:
> DNS information is clearly public information.  But that
> does not mean that one needs to publish *who* is accessing
> that public data.

Another way in which one could conceivably do that is by issuing
bogus requests, (i.e. padding) which attempts to mask not who is
asking but which answers are of interest.

That wouldn't have to be a case of sending queries for randomly
generated names, but could be based on some form of gossip between
a bunch of e.g. recursives or something. So the bogus request that
one sends out might actually be for a domain that was a real
request from another gossipy recursive a while ago.

I suspect that there's not much to be gained by doing that in
the end, and it'd clearly have costs, (though with gossiping
one might limit those by getting a lot of cache hits) but I
wonder if anyone has looked at this kind of thing in detail
already?

A v. quick search didn't turn up that much, though [1] seems
to be proposing something along these lines.

Cheers,
S.

[1] Federrath, Hannes, et al. "Privacy-preserving DNS: analysis of
broadcast, range queries and mix-based protection methods." Computer
Security–ESORICS 2011. Springer Berlin Heidelberg, 2011. 665-683.
http://202.154.59.182/mfile/files/Information%20System/Computer%20Security%20-%2016th%20ESORICS%202011/Chapter%2036%20Privacy-Preserving%20DNS%3B%20Analysis%20of%20Broadcast,%20Range%20Queries%20and%20Mix-Based%20Protection%20Methods.pdf

_______________________________________________
dns-privacy mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dns-privacy

---

From: Stephen Farrell <[email-masked]>
Date: Thu, 23 Oct 2014 20:51:52 +0100

> Essentially, all of the above calls for a Threat Model in these

Yes, a good bit of work would be required before any such
scheme could be recommended. That work would require both
design/analysis and some experiments I reckon.

But I'd be slightly (not hugely) less pessimistic than you
I think. Taking your scenario where we assume confidentiality
via crypto is deployed for stub<->recursive, one could
further assume that some set(s) of recursives might gossip
amongst one another (or with some service(s)) about which
names they've seen being requested (in a privacy friendly
manner of course:-) and then use those names for the fake
queries. I think that could be done and could if there
were few users behind each recursive amortise some privacy
protection over all those users. But not sure if the costs
would be worth it.

S.