Re: [Add] ECS privacy concerns, alternatives?

[Puneet Sood <[e-mail]>]

[Sorry for not replying to the thread. This is a response to
https://mailarchive.ietf.org/arch/msg/add/D_eoqhhz0m0sNzSW2fWdt_mcjCY#]

>From Brian Dickson <[e-mail]> Wed, 17 April 2019 19:18 UTC
>
> 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.

I think this can be solved by having the recursive resolver probe for
ECS support for a zone. If an authoritative nameserver serves a zone
that does not support ECS, it can respond w/o the ECS option
(https://tools.ietf.org/html/rfc7871#section-7.2.1). A recursive
resolver can use this as a signal to not send ECS to the nameserver
*for that zone* in the future. The recursive resolver would need to
probe periodically to handle the situation when the ECS support
changes.

What am I missing here?

-Puneet

>
>
>
> > 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