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

Tom Herbert <tom@herbertland.com> Sat, 04 November 2017 16:34 UTC

Return-Path: <tom@herbertland.com>
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 2123813FB7D for <ideas@ietfa.amsl.com>; Sat, 4 Nov 2017 09:34:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.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 QFsYI6r4ImSo for <ideas@ietfa.amsl.com>; Sat, 4 Nov 2017 09:34:09 -0700 (PDT)
Received: from mail-qk0-x231.google.com (mail-qk0-x231.google.com [IPv6:2607:f8b0:400d:c09::231]) (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 D987813FB8F for <ideas@ietf.org>; Sat, 4 Nov 2017 09:34:08 -0700 (PDT)
Received: by mail-qk0-x231.google.com with SMTP id x195so962778qkb.12 for <ideas@ietf.org>; Sat, 04 Nov 2017 09:34:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=N2cJJmGPQB3YYPqVgzmP/XInW/7BxdRmLIQi8CY91Pg=; b=SLVMLd1oUhfPI8BfXMj5rbfed6hDXq6K4OR06KM95pN1s8sRFVay6VEUu3Eknxkenb nEcdMNlogGqHmeEGA3lu/Lbru7Csbu0m4jjrERRBAStnd4yWFmhgARpNTFx65+7adnnD Y+iemAysANswGEvnUCNRo8NtcUxwkLkgG2liqPH+fhtUXJ//dQttkxSZBfvH8dLXypvk jN051OnphMpC/0WdXjYUGsFcTo7iSuKSD5lQuYXJhGvPqCPneYdDC/T+MsqzVlgFRwVx KXbNca05EGG46tXUUy3s46pl0wkTcWfHZxe6bQGZK9/OVrLgMGjxsjyU6vgT8gaOj318 2urg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=N2cJJmGPQB3YYPqVgzmP/XInW/7BxdRmLIQi8CY91Pg=; b=RO7DBojluzvBVzle9dIZybK6MMaegc+VATqYKHm4RsGq28uWtSmmnG01Jyinmw+6V3 vpNiqjIQErz9wUUkzhhXfPXfZGoDxwe01AdrD4rzTCizlVLLIMKYPBjMW+tCp88PWkHz PQm3PWONT35thtmJSmVQOO0iC4lLtP3AGlj591huAZCMmzAxa47C0Kga1UB0nP1P2vgv 4/dkMv85//8Cz1s/xHFr6PAvxiVAPGqr8xLXk+jIVq7d4Sp2MRwbeV7XLF4LRGkalwJx 756SSyslE3YxqNLxLNlNY3iBk3EaH4OIA79pHOFgeYIXlJGlbNW3ZQ5o5b4UpiCRHzy5 848w==
X-Gm-Message-State: AJaThX5W4mS5fOFP8ZauXGk4QJU/bQqw5n62jhgaTNVHErFlD4esnllm 4p8GwYU8aNlpItoEubAbEfkACC6HrQIlaZyhzx5kaw==
X-Google-Smtp-Source: ABhQp+T6kd5WKzMvnG7nDu0/M2o48uS3IEAY6PhlJ7ZYBWKFNSM1x/PE0uCmDI0e8xl2J4KRyHvmd9jjUPl/5+tz73o=
X-Received: by 10.55.148.70 with SMTP id w67mr15088843qkd.102.1509813247785; Sat, 04 Nov 2017 09:34:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.54.4 with HTTP; Sat, 4 Nov 2017 09:34:07 -0700 (PDT)
In-Reply-To: <20171103175258.GA6808@faui40p.informatik.uni-erlangen.de>
References: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <dd2c3bd5-dd37-109b-2e81-0327db4daa09@cs.tcd.ie> <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>
From: Tom Herbert <tom@herbertland.com>
Date: Sat, 4 Nov 2017 09:34:07 -0700
Message-ID: <CALx6S34g99F=6WZJWUfxRjPbYcBaRZzhSjC0DeNev3GY6mLUBw@mail.gmail.com>
To: Toerless Eckert <tte@cs.fau.de>
Cc: Christian Huitema <huitema@huitema.net>, Padma Pillay-Esnault <padma.ietf@gmail.com>, "ietf@ietf.org" <ietf@ietf.org>, "ideas@ietf.org" <ideas@ietf.org>, Dino Farinacci <farinacci@gmail.com>, "lisp@ietf.org list" <lisp@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/AGBcQi4h6nmUaDAdPyha6wNZ2SA>
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: Sat, 04 Nov 2017 16:34:11 -0000

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

> 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 :-) ). Some
trust is needed out of necessity to do anything useful, but we should
always be searching for ways to further minimize that. A good example
is turning up the TLS on the Internet; this eliminated the need to
trust the network with our plaintext. 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.

Tom