[Add] ECS privacy concerns, alternatives?

[Brian Dickson <[e-mail]>]

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.

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.