Re: [Add] ECS privacy concerns, alternatives?

[Brian Dickson <[e-mail]>]

On Wed, Apr 17, 2019 at 11:35 AM Joe Abley <[e-mail]> wrote:

> On 17 Apr 2019, at 14:16, Brian Dickson <[e-mail]>
> wrote:
>
> 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:
>
>
> So, to briefly join the threads just as further illustration to what I'm
> talking about, what you're doing here looks a lot like trying to engineer a
> solution for people you don't know based on requirements you're guessing
> at. This seems unlikely to converge on anything useful.
>
>
Actually, on this point, I beg to differ.

What I am trying to do is separate out two or three classes of
problem/solution, and avoiding having a single solution (with more
complexity and cost) imposed on the rest of the DNS authority service
community.

I am very happy to leave the specifics of the "secret sauce" behind the
curtain.

I'm trying to find a way of distinguishing the "secret sauce" folks from
the vanilla flavor folks, prior to the "established phase", so that what
"established phase" looks like might be different (e.g. encrypted or not).

I'm trying to do that distinction, upstream of established phase, for the
benefit of those not using any special sauce, so that the cost of "vanilla"
doesn't rise to being the same as the cost of "special sauce".

And, I am doing this based on the requirements of a substantial portion of
the non-"special-sauce" constituency, that portion of which I represent,
whose  requirements I not only know, but am responsible for.

The fundamental question is, for me, whether it is possible to determine
whether a given authority provider requires encryption, based on the
dependency it has on ECS (so that it can provide "special sauce")
If the authority provider does not require encryption, I would like to
facilitate that, rather than always require authority providers to offer
encrypted transport.

I'm completely open to mechanisms that facilitate this divergence.

There is not yet (AFAIK) consensus regarding requiring
recursive-to-authority encrypted transport, and in the absence of such
consensus, believe it is imperative that both encrypted and unencrypted
transport options be supported.

The resolvers may choose not to send ECS over unencrypted transport, and as
long as that is a supported mode (with whatever mechanisms are required), I
have no problem with resolvers and authority servers doing whatever they
want over their encrypted channels.

(BTW, this isn't to say that we don't also represent a substantial number
of zones that do want ECS. We do, and do want to offer and use encrypted
transport for those.)

I am happy to lead any standardization effort (i.e. doing an internet
draft) for the "geo" alternative to "ecs", and am also happy to let the
"geo" thing go, as long we can discuss whether a "no-ecs, no encryption"
option might be feasible.

The "no ECS requirement" I'm speaking of, represents about 40% of the DNS
zones served globally, who are our customers. That we are one provider with
that customer base isn't as relevant, so much as that there are 40% of the
zones with no need for ECS, and that the interaction between public
resolvers and authority servers should be, IMHO, negotiable with respect to
encrypted transport.



> Being able to separate away 99% of the resolution problem in the lifetime
> of a session ("established phase") into something that can be said not to
> have any privacy or access control concerns beyond those that already exist
> in the service being used means that all of the traffic engineering
> required there can continue to be done behind the curtain, engineered with
> a full serving of commercial advantage and richly flavoured with special
> secret sauce. I'm not saying this is without complication or is something
> that exists today, far from it: but it at least puts the design and
> implementation in the hands of the service architects who know what they
> need and, crucially, the details don't necessarily need wide exposure and
> standardisation.
>

I agree that there is no specific requirement for standardization within
the "special sauce" community. I was hoping that there might be some
interest and value in a standardized "special sauce Lite" over and above
the "special sauce" community. If not, no big deal.


>
> If there's to be an impact on performance from privacy, e.g. from a less
> sophisticated (even empty) set of available mechanisms available to do
> traffic steering at response time, it seems like it'd be really nice for it
> to be brief (e.g., "initialisation phase").
>

I agree whole-heartedly.

I also think that the "initialisation phase" represents one place where
security is extremely important, specifically in validating the identify of
the service end-point. A lot of trust regarding privacy is placed on the
end-point, so it is important that that trust not be misplaced. But I think
that is subject for a separate thread.

Brian