Re: [Add] ECS privacy concerns, alternatives?

Erik Kline <ek@loon.com> Thu, 25 April 2019 21:36 UTC

Return-Path: <ek@google.com>
X-Original-To: add@ietfa.amsl.com
Delivered-To: add@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB5A41202BC for <add@ietfa.amsl.com>; Thu, 25 Apr 2019 14:36:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.499
X-Spam-Level:
X-Spam-Status: No, score=-9.499 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=loon.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5jje_gkRbhgD for <add@ietfa.amsl.com>; Thu, 25 Apr 2019 14:36:17 -0700 (PDT)
Received: from mail-io1-xd2c.google.com (mail-io1-xd2c.google.com [IPv6:2607:f8b0:4864:20::d2c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2430B120261 for <add@ietf.org>; Thu, 25 Apr 2019 14:36:17 -0700 (PDT)
Received: by mail-io1-xd2c.google.com with SMTP id y6so1288551ior.5 for <add@ietf.org>; Thu, 25 Apr 2019 14:36:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=loon.com; s=google; h=mime-version:references:in-reply-to:reply-to:from:date:message-id :subject:to:cc; bh=InOFG33nQ5BRBo6RV3gr3fFS/pEH6wxkBnvZyYnmu5A=; b=D+Rq/OWxGbyTIBLEhRBqPhJecHoLHYoj1O6e30KPi4JbJWjQ4US5/bYS00iVibBgPE VqSXLB2cMZmZ0HTCCKHvDNHiLmZcHFpHRxU08cOWBqI5AIDT02V7bjFfBjU0cWJCPTVs Lc2Am1ELG/oeAKCjMzbKvNUkzKf/nAtQA7gzg=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:reply-to :from:date:message-id:subject:to:cc; bh=InOFG33nQ5BRBo6RV3gr3fFS/pEH6wxkBnvZyYnmu5A=; b=Yv9UFXMSpMjQBaq3ZzSiC6EjdLTNXXP+IzjKxjwRQ7bEWnLtfWV76QZxNfGbKwk3m7 zAY0H2xGsqY3zSsWsqpqlPrVxAFzQeTwH0lhZDk2n2GH8hPB+znMwbXsAm7+BGmAn06b kAbNj3jtCsprP/c5A/h2GbsaJm727GcEG0tvmIPOEdyeXfChZdfEdqqISQyBNDDVTg/8 jQ5mkfe/28rWIYiKcPAh50iwvUhYlVFhCFwrqUfqehUxWqxYbecYyugxdCPGmH77km9y MIdYswXVenVCYSqldNyMSXXhxbJF8wnZ2FPsVzyTFql9BVPcP/gVtcBH5yhuoT5QJFmS zZLg==
X-Gm-Message-State: APjAAAU0gqBX9GAvTMCGe69WLhhBRMp63XcijMKnB+U37Q9/cCwGvgSq Z6d1koldq7tVk7DDS4Ep5L16v6p5mswNjrocJwOCej9YEzQ=
X-Google-Smtp-Source: APXvYqzyJeiMHKg4z8bLCM0/qciAjaf2wpu2Uq3yjAf768kIJNUVzSkwLHxRfqPoM0EFYFbEeG5Df2hj3IT26kYVvx8=
X-Received: by 2002:a6b:2c92:: with SMTP id s140mr11321208ios.114.1556228175645; Thu, 25 Apr 2019 14:36:15 -0700 (PDT)
MIME-Version: 1.0
References: <CA+9_gVvWHUR5OFbBa9zf1+BSxcQNO8njKJEYp8FBt-=hJYESMA@mail.gmail.com>
In-Reply-To: <CA+9_gVvWHUR5OFbBa9zf1+BSxcQNO8njKJEYp8FBt-=hJYESMA@mail.gmail.com>
Reply-To: ek@loon.com
From: Erik Kline <ek@loon.com>
Date: Thu, 25 Apr 2019 14:36:03 -0700
Message-ID: <CAAedzxr9h1PAo3Z0AUsDPo2CORrxkP0emr9KUX3osOPG21Ve-g@mail.gmail.com>
To: Puneet Sood <puneets=40google.com@dmarc.ietf.org>
Cc: add@ietf.org
Content-Type: multipart/alternative; boundary="00000000000099a8650587619beb"
Archived-At: <https://mailarchive.ietf.org/arch/msg/add/tUvpWXz_QXrqw84hflvR-MGHXVE>
X-Mailman-Approved-At: Thu, 25 Apr 2019 14:37:30 -0700
Subject: Re: [Add] ECS privacy concerns, alternatives?
X-BeenThere: add@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Applications Doing DNS <add.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/add>, <mailto:add-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/add/>
List-Post: <mailto:add@ietf.org>
List-Help: <mailto:add-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/add>, <mailto:add-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 25 Apr 2019 21:36:21 -0000

On Thu, 25 Apr 2019 at 14:06, Puneet Sood <puneets=
40google.com@dmarc.ietf.org> wrote:

> [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 <brian.peter.dickson@gmail.com> Wed, 17 April 2019
> 19:18 UTC
> >
> > On Wed, Apr 17, 2019 at 11:35 AM Joe Abley <jabley@hopcount.ca>; wrote:
> > > On 17 Apr 2019, at 14:16, Brian Dickson <brian.peter.dickson@gmail.com
> >;
> > > 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?
>

My recollection from the DPRIVE 104 discussion about TLS to the
authoritative was that a non-probing method was considered preferable.

Generalizing from there, I think folks want to minimize the amount of
"probe and remember" activity that has to take place (no matter the problem
domain).

>
> >
> > > 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
>
> --
> Add mailing list
> Add@ietf.org
> https://www.ietf.org/mailman/listinfo/add
>