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

Alexander Clemm <alexander.clemm@huawei.com> Wed, 04 October 2017 18:48 UTC

Return-Path: <alexander.clemm@huawei.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 5DBD4133055; Wed, 4 Oct 2017 11:48:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.22
X-Spam-Level:
X-Spam-Status: No, score=-4.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] 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 nxWoPZ4WGi-z; Wed, 4 Oct 2017 11:48:11 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C64EC133023; Wed, 4 Oct 2017 11:48:10 -0700 (PDT)
Received: from 172.18.7.190 (EHLO LHREML714-CAH.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DPX33583; Wed, 04 Oct 2017 18:48:08 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by LHREML714-CAH.china.huawei.com (10.201.108.37) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 19:48:07 +0100
Received: from SJCEML521-MBX.china.huawei.com ([169.254.1.175]) by SJCEML701-CHM.china.huawei.com ([169.254.3.215]) with mapi id 14.03.0301.000; Wed, 4 Oct 2017 11:48:03 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: "stephen.farrell@cs.tcd.ie" <stephen.farrell@cs.tcd.ie>, "tom@herbertland.com" <tom@herbertland.com>
CC: "ideas@ietf.org" <ideas@ietf.org>, "phill@hallambaker.com" <phill@hallambaker.com>, "ietf@ietf.org" <ietf@ietf.org>
Thread-Topic: [Ideas] WG Review: IDentity Enabled Networks (ideas)
Thread-Index: AQHTOT4HtvaRdsDDgEqucGYSnlXKNaLMpUwAgAefuYCAABZuAIAABMSA//+mfxA=
Date: Wed, 4 Oct 2017 18:48:03 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie> <CAMm+Lwg61PGrcmu=-e8ciD6Q+XmEaWWDys4g2M657VOjWmaGcg@mail.gmail.com> <CALx6S370-TuoUicWep5vV2NjLPS4d-HP1qVxW_nGrxhBLw6Eug@mail.gmail.com> <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie>
In-Reply-To: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.213.48.103]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
X-Mirapoint-Virus-RAPID-Raw: score=unknown(0), refid=str=0001.0A020206.59D52CE9.009B, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0, ip=169.254.1.175, so=2013-06-18 04:22:30, dmn=2013-03-21 17:37:32
X-Mirapoint-Loop-Id: ffc79e8c6a44093f62df7a0f42f4cdce
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/TNjccwgP0ysFVPHCY7KT45q01cs>
Subject: Re: [Ideas] 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: Wed, 04 Oct 2017 18:48:14 -0000

There were a couple of things raised in the overall thread that I just wanted to quickly respond to:

Clearly privacy is an important issue and concern.  The current charter proposal includes a requirement for a detailed analysis of this aspect.  If this aspect needs to be expanded, sure, let's do this.  

Everyone seems to be jumping up and down regarding the use of the term of "identity" as if a foregone conclusion that this is a synonym for "privacy invasion".   However:
- "Identity" does not imply "personal identity".  Really, this is an identifier scheme for endpoints.   Perhaps even "identity" is a misnomer.  If you will, identity as conceived in the context of IDEAS is a second level of identifier that does not have to be exposed over the data plane
- Because of this, it may result in greater privacy than existing schemes, not less.  It enables you, for example, to obfuscate endpoints to outside observers as you wouldn't need to use personal unique long-lived identifiers, quite the contrary.  
 - There is also a security dimension here. If I am victim of a phishing attack because my network information (like today) is exposed to botnets, phishers etc who can hide from me (but not I from them) and remain anonymous or impersonate legitimate users, I do consider this a very serious threat also to my privacy.  How can IETF counteract such threats?  I think that IDEAS, if done right, can provide a contribution here.  

One aspect that has been missing from the discussion is the question whether there is a distinction between the network provider who provides GRIDS services and an outside attacker / observer.  I think this distinction is important.  The way I see it, if done right (sure, big "if", and requiring detailed analysis), IDEAS as I would envision it can contribute greatly to provide greater security and privacy from outside attackers.  At the same time, as it is currently envisioned, there clearly is a trust relationship between an entity and the provider of "its" GRIDS services.  The mapping database will have information about locator-identifier and identifier-identifier mappings, so GRIDS will know which identifiers its endpoints are using.  Clearly, if this trust is abused because the provider cannot be trusted, if you are concerned that it sells your endpoint’s information to the mob or a suppressive government, there is an issue.  However, when concerned about this scenario, it seems to me one would have equal reason to e.g. not trust your mobile service provider either, who can track you, knows your location, and has your customer data.  

--- Alex


> -----Original Message-----
> From: Ideas [mailto:ideas-bounces@ietf.org] On Behalf Of
> stephen.farrell@cs.tcd.ie
> Sent: Wednesday, October 04, 2017 9:35 AM
> To: tom@herbertland.com
> Cc: ideas@ietf.org; phill@hallambaker.com; ietf@ietf.org
> Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
> 
> 
> 
> On Wednesday, 4 October 2017, Tom Herbert wrote:
> > On Wed, Oct 4, 2017 at 7:57 AM, Phillip Hallam-Baker
> > <phill@hallambaker.com> wrote:
> > > On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell
> > > <stephen.farrell@cs.tcd.ie>
> > > wrote:
> > >>
> > >>
> > >> As currently described, I oppose creation of this working group on
> > >> the basis that it enables and seemingly encourages embedding
> > >> identifiers for humans as addresses. Doing so would have
> > >> significant privacy downsides, would enable new methods for
> > >> censorship and discrimination, and could be very hard to mitigate
> > >> should one wish to help protect people's privacy, as I think is
> > >> current IETF policy.
> > >>
> > >> If the work precluded the use of any identifiers that strongly map
> > >> to humans then I'd be ok with it being done as it'd then only be a
> > >> waste of resources. But I don't know how that could be enforced so
> > >> I think it'd be better to just not do this work at all.
> > >>
> > >> S.
> > >
> > >
> > > +1
> > >
> > > I know how to restrict the work to 'meaningless' identifiers,
> > > require that the identifiers be the output of a cryptographic algorithm.
> > >
> > > Now strictly speaking, this only limits scope to identifiers that
> > > are indexical as opposed to rendering them meaningless but I think
> > > that was the sense of it.
> > >
> > >
> > > Nöth proposed a trichotemy of identifiers as follows
> > >
> > > * Identity, the signifier is the signified (e.g. data: URI)
> > >
> > > * Indexical, the signifier is related to the signified by a
> > > systematic relationship, (e.g. ni URIs, SHA256Data), PGP
> > > fingerprints etc.)
> > >
> > > * Names,  the signifier is the related to the signified by a purely
> > > conventional relationship, (e.g. example.com to its owner)
> > >
> > >
> > > There is a big difference between attempting to manage indexical
> > > signifiers and names. Especially when the people trying to do so
> > > refuse to read any of the literature on semiotics.
> > >
> > > Names are problematic because the only way that a conventional
> > > relationship can be implemented is through some sort of registration
> > > infrastructure and we already have one of those and the industry
> > > that manages it has a marketcap in the tens of billions.
> > >
> > > Identifiers do lead to tractable solutions. But, this proposal looks
> > > a bit unfocused for IRTF consideration, an IETF WG? Really?
> > >
> > Identifiers are equivalent to addresses in that they indicate a node
> > in the network for the purposes of end to end communications. The only
> > difference between identifiers and addresses is that identifiers are
> > not topological. Virtual addresses in network virtualization are also
> > identifiers. So the security properties are the same when considering
> > privacy. For instance, if applications use temporary addresses for
> > privacy, it would have equivalent properties using temporary
> > identifiers. In fact from the application POV this would be
> > transparent. It could get a pool of apparently random addresses to
> > choose from as source of communication, it shouldn't know or even care
> > if the addresses are identifiers.
> >
> > Identity is a completely separate concept from identifiers. Is not
> > required in any of the identifier/locator protocols and AFAIK none of
> > them even mention the term. There is no association of an identity of
> > user behind and identifier any more than there is an association of
> > identity behind IP address. The fact that the words "identifier" and
> > "identity" share a common prefix is an unfortunate happenstance :-).
> 
> 
> Yes. But doesn't that mean either the name of this effort is wildly misleading
> or else the effort is hugely problematic from a privacy POV? Either way, istm
> this ought not proceed.
> 
> S.
> 
> >
> > Tom
> >
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas