Re: [Add] ECS privacy concerns, alternatives?

[Brian Dickson <[e-mail]>]

On Wed, Apr 17, 2019 at 9:04 AM Erik Nygren <[e-mail]> wrote:

>
> 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).
>>
>
> Unfortunately, Geo is only one of the dimensions used.  At least some of
> the common and heavily used CDNs and other DNS-based routing services also
> need to use both ASN and in some cases the regional network location within
> the ASN.
>

Okay, so I did oversimplify. My bad.

Let's consider what the situation is, for authority servers.

Some (not all, not none) are CDNs. Some (not all, not none) are not doing
ECS at all. Some (not all, not none) are doing ECS, but only using
"vanilla" ECS functionality, via third-party IP->GEO databases/services.

The potential trade-off(s), as I see them, are:

   - possible exposure of privacy information via ECS (as currently is done
   today)
   - possible scaling problems caused by requiring encryption, to
   authorities not doing ECS, or who do ECS but could equally do "GEO"
   - public resolver/browser requirements/agreements imposing changes on
   third parties (encryption)

Given that the driver for these changes is "ADD" (applications doing DNS,
specifically here browsers), I'm interested in whether there are ways of
handling these that can balance those issues.

For example, if the public recursive required that the authority support
encrypted transport before doing ECS, and had the ability to fall back to
GEO over non-encrypted transport, would that be feasible?
The public resolver would probably need to keep track of authority servers
that do/don't support encryption, as an optimization.
If the fall-back didn't ever result in ECS over unencrypted sessions, that
would make it mostly immune to downgrade attacks.
This would also provide for a smooth deployment scheme; this could be logic
deployed even before the resolver-to-auth encryption is standardized, with
no "flag day" required.

Since this suggestion has implications to public resolvers, it clearly
requires buy-in from them, and possibly the blessing of the browser folks
that GEO is acceptable from a privacy policy perspective. Feedback is
welcome and sought.

Thoughts?
Brian