Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)

Toerless Eckert <tte@cs.fau.de> Mon, 06 November 2017 20:01 UTC

Return-Path: <eckert@i4.informatik.uni-erlangen.de>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54D6913FB3E; Mon, 6 Nov 2017 12:01:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.199
X-Spam-Level:
X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham autolearn_force=no
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 R41QdZQirOvw; Mon, 6 Nov 2017 12:01:51 -0800 (PST)
Received: from faui40.informatik.uni-erlangen.de (faui40.informatik.uni-erlangen.de [IPv6:2001:638:a000:4134::ffff:40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0450713AF75; Mon, 6 Nov 2017 12:01:50 -0800 (PST)
Received: from faui40p.informatik.uni-erlangen.de (faui40p.informatik.uni-erlangen.de [131.188.34.77]) by faui40.informatik.uni-erlangen.de (Postfix) with ESMTP id 4950D58C4FA; Mon, 6 Nov 2017 21:01:45 +0100 (CET)
Received: by faui40p.informatik.uni-erlangen.de (Postfix, from userid 10463) id 320C6B0D0C7; Mon, 6 Nov 2017 21:01:45 +0100 (CET)
Date: Mon, 06 Nov 2017 21:01:45 +0100
From: Toerless Eckert <tte@cs.fau.de>
To: Tom Herbert <tom@herbertland.com>
Cc: "ideas@ietf.org" <ideas@ietf.org>, "lisp@ietf.org list" <lisp@ietf.org>, Christian Huitema <huitema@huitema.net>, Dino Farinacci <farinacci@gmail.com>, Padma Pillay-Esnault <padma.ietf@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>
Message-ID: <20171106200144.GA21604@faui40p.informatik.uni-erlangen.de>
References: <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <1f254140-1340-6c7d-9c73-e7137562c685@gmail.com> <fa644cc2-161f-8884-3445-2b50d2c2ad23@htt-consult.com> <cf2ca920-f2d2-b65e-05eb-ebe3c30b76d1@huitema.net> <CAG-CQxrdS9L+2+bN=1NcPGuztn4U4OwSWUiNaVcS9Bsm2mtpfA@mail.gmail.com> <b18459d1-7ce1-b83d-787d-9066267d584b@huitema.net> <20171101172146.GA12437@faui40p.informatik.uni-erlangen.de> <CALx6S34Bkv4ipyA5si4KkW7VaYU6A=3=cPpRo_ss00H+vDms-w@mail.gmail.com> <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de> <CALx6S34g99F=6WZJWUfxRjPbYcBaRZzhSjC0DeNev3GY6mLUBw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CALx6S34g99F=6WZJWUfxRjPbYcBaRZzhSjC0DeNev3GY6mLUBw@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/ZzKgUGuKLJApE3c-6aaQ107McTM>
Subject: Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: "Discussions relating to the development, clarification, and implementation of control-plane infrastructures and functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>, <mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>, <mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Nov 2017 20:01:54 -0000

On Sat, Nov 04, 2017 at 09:34:07AM -0700, Tom Herbert wrote:
> On Fri, Nov 3, 2017 at 10:52 AM, Toerless Eckert <tte@cs.fau.de> wrote:
> > Thanks, Tom, inline
> >
> > On Thu, Nov 02, 2017 at 08:30:11AM -0700, Tom Herbert wrote:
> >> Toerless,
> >>
> >> That maybe true, but personal devices, such as smart phones and cars
> >> that are associated with individuals, are hardly going away anytime
> >> soon. How addresses are assigned to these devices has a material
> >> impact on individual privacy. Even right now there are two long
> >> threads on v6ops right now that are delving precisely into privacy of
> >> IPv6 addresses that may be relevant. This includes discussion about
> >> CGNAT and efforts by some governments to illegalize it because the
> >> privacy it gives is too strong for law enforcement.
> >
> > Sure. All i was saying is that we should not dismiss solutions if they
> > do not help to improve privacy. It reminds me of the congestion control
> > principles and the fact that a lot of money is made with video in
> > controlled networks without congestion control. As in: "Sorry, we couldn't
> > build a great solution for sensor devices in manufacturing plants because
> > those solutions wouldn't pass the privacy bar".
> >
> > I am not even aware if we have good characterizations of solutions
> > vs. privacy like IMHO we have for congestion control, but of course its
> > a more complex topic. (IMHO: lot more cases IMHO to distinguish).
> >
> > That being said, i would of course love to see that we leverage IDEAs to
> > also create options that (could) enhance privacy, i just don't think that
> > we will make a lot of progress if we can not do this work in a WG but
> > if all the complex issues have to be resolved on pre-wg mailing lists before
> > even charters are accepted. This is part of whats wrong with the IETF
> > if i may say so.
> >
> > For example, Christian contested that long lived identifiers help to
> > improve privacy (for device = individual case) and those arguments about
> > privacy had the IESG turn their opinions.
> >
> > IMHO: The long-lived identifiers are meant to be functionally limited. You do
> > increase the bar of identifying an individual when you do this because the
> > web applications need to do more work to correlate application layer
> > information across multiple functional identifiers.
> >
> > So, how & where do we even create a common understanding about the qualitative and
> > quantitative privacy benefits of technology options if not in a WG. Functional
> > identifiers just being one example.
> >
> > Even more fundamentally: If each individual application layer function requires
> > authentication via e.g.: government, google or facebook ID, and all those
> > web services are free to correlate their information in the backend, any
> > network layer privacy work is just like growing organic tobacco.
> >

> In the base case scenario,
> it should be impossible for a random intermediate node in the Internet
> to determine who is communicating to whom (identity), where someone is
> communicating from (location), and what they are saying (content).

As an individual i agree. An individual who needs to VPN
across his home gateway routers in different countries to get access to
entertainment options when being abroad. But then there are so many paychecks
people want to live off: 

There is a lot of "Internet" business riding on geo-location of locators
(for better or worse). So, when it comes to IESG review of proposed work,
how would a scheme be vetted wrt.  those business models ? 

If we would take this geo-location awareness away from the network layer,
i can already see how any web browser would become even more DRM encumbered,
reaching down into the system to also protect reading of GPS location, and
i have to run from my hotel room outside to the street to catch a GPS signal
to let me watch my movie. Like those pico-cells from ATT.

Likewise, service-provider want to have subscriber-IDs to be able to treat
traffic from multiple subscribers fairly because there is really no good way
to do this without an explicit subscriber-ID if you want real address
anonymity (whether its identifier or locators). And that requirement i actually
agree to as an individual even a lot more than the geoloc one.

IMHO we must as the IETF be a lot more flexibility with allowing different
requirements and business models, else we will just see ore and more
of the counter reaction nicely summarized in http://queue.acm.org/detail.cfm?id=1242499>

I like a well standardized and documented IETF solution that exposes
end-user data a lot more than the secret dealings at application level
that happen today. Especially when we could start thinking of how to
guarantee that we provide means for the end-user/app to device what to
present to whom and why.

> > Which is why i really would like to know what the state of requirements/BCP etc.
> > is re. privacy at app layer in the IETF, because without that knowledge, i can
> > only define the privacy benefits of a network layer enhancement under the
> > ASSUMPTION of particular application behavior.
>
> I don't think that's true. Privacy enhancements at the network layer
> are needed to prevent inferences of PII by third party using just
> network layer information that might be passively intercepted.
> Knowledge of the application is not needed.

Right. I can make life for those third parties harder by introducing what
i called functional identifiers, where ultimately every type of interaction
you do uses a different identifier and can therefore at network layer
by passive observers not be correlated into a single identity. But introducing
that type of work into network layer makes only sense if we want to assume
that there is no correlation across multiple functions at the application
layer anyhow. That was the example.

> > My impression of IETF policy is "you have to trust the web services
> > provider (not to share/correlate/abuse user/client information)" and in the
> > same breath "you can not trust the network service provider (to behave in the
> > same way)". Would love to get pointed to documents proving this impression to
> > be wrong. Especially the option that there can be network providers that
> > users may want to trust more than arbitrary web services providers should IMHO
> > be acknowledged. And thats definitely an option i think is worthwhile to build
> > solutions against.
> >
> I doubt there's any IETF RFC or BCP stating whom were required to
> trust as a MUST. Personally, I don't inherently trust web service
> providers, network service providers, government, vendors, or really
> anyone else involved in communications (including myself :-) ).

+1

> Some trust is needed out of necessity to do anything useful, but we should
> always be searching for ways to further minimize that.

The more you want to do across the Internet, the more you need to trust
those web services providers with your data. The real challenge is create more transparency
in those web service providers to allow for more verification of what they do. 

And why the heck should i not be able to get better services from network service
providers ? What they would need to know for interesting services is so much
less than what app providers are collecting about me. Why would i oppose a
subscriber ID so a network service provider can provide fairness better ?

> A good example
> is turning up the TLS on the Internet; this eliminated the need to
> trust the network with our plaintext.

The problem with TLS is that it is evolving in a way that will again lead to
a weapons race. For example the fact that 1.3 removed totally the option for
no-encryption. Therefore eliminating the option of apps who need observable,
authenticated traffic to rely on just TLS. Or the fact that it mandates
encryption of certs so you can not even authenticate the identify of a web
service (not the client). There are good reasons why you want to have this
profile, but there are also good reason why you want othre profiles, and those
get consistently shot down in the IETF. And thats bad politics.

> I believe a similar thing will
> happen with addressing, we'll figure out how to eliminate all PII from
> addresses so that we don't have to trust the network to not be making
> inferences that breaks privacy.

The VPN service providers to access netflix abroad are an interesting
data point in this battle. Obviously i need to trust them to keep my
identify "private". Netflix did recently block a lot of them. What would
happen if ever more subscriber would use SPs offering that type of
locators. Would the OOT provider like hulu/netflix wake up and relax
geo-locking  Or do we get the GPS geoloc as i fear ?

In any case: a) if we want to get more addressing privacy, it would be good
to discuss the expectable outcomes of that, and b) i can not see how
to create that privacy without putting more trust into some entities
(such as the access==VPN SP).

Cheers
    Toerless

> Tom
> 
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas

-- 
---
tte@cs.fau.de