Re: [Add] ECS privacy concerns, alternatives?

[Brian Dickson <[e-mail]>]

On Tue, Apr 16, 2019 at 4:10 PM Mark Delany <[e-mail]> wrote:

> On 16Apr19, Brian Dickson allegedly wrote:
>
> > That's why I indicated that by "geo", I meant OPTIONALLY more
> fine-grained
> > than country-level:
> >
> > >country and sub-country levels, e.g. ISO-3166, with 3166-1 being
> > countries, and 3166-2 being sub-country 3-letter codes.
>
> I hope I'm not mis-understanding you, but no level of fine-grained GEO
> provides suitable input for topology-based solvers. I want to know
> which networks you are connected to and even a high-precision lat/long
> doesn't tell me that. Your /24 does.
>

Yes, I understand. For you, ECS works fine, and GEO doesn't.
So, continue to use ECS, and don't use GEO.

I don't understand why that would be a problem, unless resolver operators
choose not to continue to send ECS.

They might make that decision based on the requirements to encrypt
if ECS is used. Or, they may decide doing ECS is worth the encryption cost,
and encrypt and use ECS.
(Those issues would be something for you to take up with them, IMHO.)

Other auth servers might make different decisions on ECS, for whatever
reason.
Those other auth folks might not want to encrypt, and may want to use GEO.
For them, that may be good enough.

Them doing GEO doesn't impact you doing ECS, unless I'm missing something
obvious.

GEO might not be as good as ECS, but there are plenty of cases where the
difference is moot.
E.g. if the zone owner (!= auth operator) has services in only a few
places, and they don't benefit
from any granularity improvement.


>
> > I'm pretty sure we are not in a one-size-fits-all world here.
>
> For sure, but fine-grained GEO raises more questions. What if you want
> to send sub-country codes to trusted auths to get better resolution
> but only country codes to less trusted auths to get better
> privacy. How is that provisioned in end-user equipment and kept
> current?
>

Don't know, don't particularly care, honestly.
I would expect that to be something managed on a per-auth-provider basis,
or maybe negotiated somehow?

What does "trusted" mean, privacy or something else?


>
>
> The other thing is that auths can play discovery tricks to correlate
> queries with client IPs anyway. E.g. issue nonce IPs with very short
> TTLs then watch for inbound connections. (Finally a killer app for
> IPv6!). So I think we want to be crystal clear about what privacy risk
> we think is being solved and whether it's lulling people into a false
> sense of security or not.
>

I think that would imply cooperation between auths and those seeking to
defeat the privacy of Do*.
I don't think anything done resolver-auth has the ability to impact that
cooperation, if it exists.

I.e. if an auth does that nonce trick, it doesn't matter whether the
resolver encrypts the connection,
it doesn't matter whether ECS is used or GEO is used. The client's
association is discovered on
the data connection established based on the DNS answer.

Maybe the resolver can implement counter-measures on behalf of clients,
maybe not.
But the issues is invariant over encrypted/clear or ECS or GEO, as far as I
can tell.

In fact, I'd argue the granularity aspect of GEO may provide better "cover"
to clients,
since the recursive could do any number of things for low TTLs that
compensate.
I'm not condoning any particular countermeasure, only suggesting that the
existence
of countermeasures which align better and scale better with GEO, could be
more
effective. Examples might be, requerying and keeping a variety of answer
sets, and
serving them randomly, i.e. a combination of "hammer" and "serve-stale".

Privacy, like security is hard. Trying to mesh efficient/accurate results
with privacy is also hard,
and may require re-thinking solutions.

There may be some need to trade off efficiency with privacy, or to consider
other means
of approaching the solution space for efficiency (with respect to topology).

E.g. maybe instead of GEO, using ASN based mechanisms, which better reflect
topology,
while offering some degree of privacy. Clearly there is non-uniformity,
since some ASNs have
very few prefixes which are small, and others have lots of large prefixes.

Thoughts on this?

Brian