Re: [Add] ECS privacy concerns, alternatives?

[Brian Dickson <[e-mail]>]

On Tue, Apr 16, 2019 at 2:31 PM Brian Dickson <[e-mail]>
wrote:

>
>
> On Tue, Apr 16, 2019 at 9:00 AM Livingood, Jason <
> [e-mail]> wrote:
>
>> And for ease of any replies, I have a separate question on CDN
>> localization via ECS. The 6th privacy requirement suggests that ECS cannot
>> be used unless there is encryption between the resolver and the
>> authoritative server, presumably via DoT. This suggests that the privacy
>> concern isn't that the network/geographic hint provided by ECS is
>> problematic in and of itself, but that it should not be observable along
>> the network path used in recursion.
>>
>> But if TRR-to-auth recursion is not available via DoT, I wonder what the
>> recommended mechanism is for providing a more privacy-protective
>> network-geographic hint to an authoritative server, in order for example
>> for a CDN to dynamically respond with a localized response. Maybe something
>> new needs to be standardized? What options do folks suggest?
>
>
> That's a great question. Apologies in advance for always providing long
> answers. :-)
>
> IMHO, the privacy issue is the IP portion, not the geo portion, of geo-ip.
>
> I may be oversimplifying the situation, but I believe the vast majority of
> authority DNS services (or proxy services in front of those) structure
> their internal representation of things as geo->answer mappings, and
> generally have some flavor of ip->geo mapping on their front-end(s).
>
> Those internal representations may be non-standard, but there are
> standards for geo representations for country and sub-country levels, e.g.
> ISO-3166, with 3166-1 being countries, and 3166-2 being sub-country
> 3-letter codes.
>
>  I think there is sufficient anonymity in using these codes instead of
> ECS, which would remove the need to encrypt the resolver-auth transactions,
> and potentially offer other benefits to auth operators which as a
> consequence, would potentially improve both the quality of results (by
> standardizing the GEO codes, and placing the ip->geo accuracy
> responsibility onto the resolver).
>
> There are other ways to improve the whole ECS model by moving to GEO. For
> example, a query to an authority server with GEO might return not only an
> answer, but also a hint about the granularity at the specific GEO code. A
> query for e.g. CA-ON might return an answer for CA-0, indicating that no
> more-specific answers within CA are available, while a query for e.g. CA
> might return an answer for CA-1 (indicating that more-specific answers are
> available, hinting that the resolver might want to ask again). The GEO
> stuff could be treated analogous to QNAME minimization; ask for the
> next-more-specific answer IFF more-specifics are available.
>

I forgot to mention another aspect of this idea: privacy-preserving
iteration. Rather than only querying for the more-specific code associated
with the client, the resolver could just as easily do queries for all of
the next-specific-level entries, possibly in parallel, possibly randomized
order. The resolver would be able to provide an answer to the client once
the particular answer it was looking for was received, and would have the
added benefit of pre-populating its cache for the other
geographically-close answers.

Brian



>
> It would require the resolver to have its own IP->GEO mapping stuff, but
> has the benefit of getting consistent results across authority providers
> (always right or always wrong, and the resolver has both the ability and
> incentive to fix any IP-GEO mapping errors).
>
> It probably helps scaling on the cache side (resolver) and zone side
> (authority).
>
> Any authorities doing ECS probably already have the GEO->zone stuff and
> possibly even encode it that way; the incremental work in supporting an
> EDNS GEO would in those cases be negligible.
>
> Honestly, if GEO can get standardized and reach critical mass, I think it
> would be valuable on its own, even without the privacy aspects, and I think
> it would be nice to use it and to deprecate ECS, eventually.
>
> Brian.
>