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

Alexander Clemm <alexander.clemm@huawei.com> Wed, 04 October 2017 22:34 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 785F01344D8; Wed, 4 Oct 2017 15:34:21 -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 d-eFzVszV2nz; Wed, 4 Oct 2017 15:34:18 -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 502BB1344CD; Wed, 4 Oct 2017 15:34:17 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml707-cah.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id DWW11452; Wed, 04 Oct 2017 22:34:15 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.301.0; Wed, 4 Oct 2017 23:34:14 +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 15:34:04 -0700
From: Alexander Clemm <alexander.clemm@huawei.com>
To: Stephen Farrell <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//+mfxCAAI64gP//oHdg
Date: Wed, 4 Oct 2017 22:34:03 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA739C@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> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAA7204@sjceml521-mbx.china.huawei.com> <dd2c3bd5-dd37-109b-2e81-0327db4daa09@cs.tcd.ie>
In-Reply-To: <dd2c3bd5-dd37-109b-2e81-0327db4daa09@cs.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.0A0C0208.59D561E7.00E9, 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: 6c3af99f58e1567df8b7e11a874c70d8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/MFzIUdin3PNwUCxazim43ozA5qs>
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 22:34:21 -0000

Hi Stephen,
Just a couple of responses inline, <ALEX>  (at the risk of making your opposition even stronger;-)
--- Alex

> -----Original Message-----
> From: Stephen Farrell [mailto:stephen.farrell@cs.tcd.ie]
> Sent: Wednesday, October 04, 2017 12:45 PM
> To: Alexander Clemm <alexander.clemm@huawei.com>om>;
> tom@herbertland.com
> Cc: ideas@ietf.org; phill@hallambaker.com; ietf@ietf.org
> Subject: Re: [Ideas] WG Review: IDentity Enabled Networks (ideas)
> 
> 
> Hiya,
> 
> TL;DR - I am now even more convinced that this ought not go ahead. (Sorry;-)
> 
> On 04/10/17 19:48, Alexander Clemm wrote:
> > 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.
> 
> TBH, I don't think that'd help, for me at least. I don't see any way in which
> such permanent strings representing identity can be defined to be usable as
> claimed and not be perniciously privacy invasive. So some promises to
> ponder the problem in charter text wouldn't do it for me. (And tbh, I've seen
> that can kicked down that road before, so I'm skeptical of such promises in
> general.)
> 
> > 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.
> 
> Sorry, what I assume is the relevant draft [1] says the "identity"
> (denoted "IDy") is a "Unique and Permanent Identity" and that "Networks
> may treat traffic differently depending on the IDy of source or destination"
> and also seems to envisage a large logical database of everyone's IDy's:
> "Identity also allows to have metadata associated it to be applied, regardless
> of which IDf is used to refer it." (Where IDf is the identifier that'll later be
> mapped to a locator via, I assume, HIP or LISP or similar.)

<ALEX> The intent is to distinguish between how you would be identified through a private/secured/authenticated control plane (which is the longer-lived "anchor" identifier) vs out in the open (shorter-lived identifiers for use on the data plane that provider greater anonymization, making it more difficult to track users by outside observers).  The assumption is that a distinction can be made between outside 3rd party observer vs provider of the GRIDS services. 

I guess a big part of the controversy and your reaction comes from the statement "Networks may treat traffic differently depending on IDy of source or destination".  I can see that this is something that needs to be reframed. The item of concern here concerns scenarios like that as a user, I might want to be able to define access rules who can contact me much like frequently done using firewall rules.  For example, no Webcams/IoT devices (part of the metadata) should contact me.  Rather than putting the onus on my end device to try and block illegitimate traffic and exposing me to DoS attacks or worse, I might want to be able to articulate a policy to that effect and ask GRIDS to not provide my locator information to e.g. a Mirai-controlled Webcam.  One question is whether we would want policies to be articulated that refer to specific identifiers.  If we were to allow such a thing, the question about how to maintain such rules immediately comes up - given identfiers are anonymized and fast changing, what sense would it make to even try to articulate such a rule?  Here it would make sense to articulate a rule along the lines of "apply this rule to the entity that the identifier refers to".   

You can disagree with this, but this is just to provide some explanation regarding background.  I don’t think these are illegitimate concerns.  So, how can we frame things accordingly?  
</ALEX>

> 
> I think it's entirely correct to jump up and down about the privacy
> consequences of the above. (Not to mention the potential censorship and
> discriminatory aspects.)
> 
>      [1] https://tools.ietf.org/html/draft-ccm-ideas-identity-use-cases-01
> 
> > Perhaps even "identity" is a misnomer.
> 
> Well, it was presumably your choice (where your == some set of the
> proponents). If that's a mistake, then it seems a fairly fatal one - to get the
> name wrong for an effort all about mapping names to identifiers;-)

<ALEX> Again, not identity is exposed on the data plane.  What term would you suggest?   </ALEX> 

> 
> > 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.
> 
> I see that argument in [1] but I'm not buying it tbh. To get that level of
> protection from such an indirection, one would have to have something like
> Tor hidden services and perhaps one would have to *not* standardise the
> mapping from human meaningful identifiers to those used as IDf, and esp.
> not the reverse mapping. Defining that reverse mapping cannot but be
> privacy invasive afaics. (There could maybe be ways to define how an already
> hashed human meaningful identifier could then be further hashed to
> become an IDy but I don't really see the point of that at all, other than to just
> standardise something for the fun of the process.)

<ALEX> Are you arguing against the problem statement of the particular solution?   
</ALEX>

> 
> > 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,
> 
> (Nit: that says nothing about being a victim of, only of being a target of, an
> attempted attack. Speaking of victims also tends not to lead to more
> objective analysis, so I think it's better to not go there unless it's relevant,
> which I don't think is the case here, because...)

<ALEX> I was using the term "I" as a figure of speech.  I am not speaking as a victim here.  As a target, sure.    
</ALEX>

> 
> I don't understand what network information you mean. If you mean email
> addresses, and are proposing that the email ecosystem change to use some
> IDf or LOC values, that doesn't seem at all realistic to me. If you don't mean
> email addresses then I don't see how any lower layer change will affect
> attempted phishes.
> The routing area is probably also the entirely wrong venue for any real anti-
> phishing effort.
> 
> That really wasn't a good example;-)

<ALEX> I am referring to locator information.  To phish me, someone needs to obtain my locator. 
I am concerned about privacy.  Do I have a right to privacy for my locator information?  
</ALEX>

> 
> > 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.
> 
> I don't see that at all. Unless I'm mistaken that seems like wishful thinking to
> me.

<ALEX> Maybe it is wishful, but I do think that these treats are real and that it is not dishonorable to try to counteract them.  Just like threats on privacy (a big concern on this thread) are real and need to be counteracted; I completely agree with this by the way but do believe we have to strike a balance with security.  </ALEX>

> 
> >
> > 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.
> 
> ISTM that introducing that GRIDS thing makes matters worse and not better,
> because, as you yourself say, it is clear that whoever has access to the GRIDS
> information would be better able to track people compared to now.
> 
> I would prefer to see fewer long lived identifiers in networking and not
> more, and this proposal introduces more long lived identifiers (erroneously
> calling those identities).

<ALEX> See above.  I really believe this will result in fewer long-lived identifiers used in the data plane.  That this would somehow mandate long-lived person-identifying identifiers on the data plane is a misconception. 
(end of my comments)
</ALEX>

> 
> Regardless of what one thinks of them, given that things like HIP and LISP
> exist, and try tackle the ID/LOC split, I see no benefit adding this extra layer
> of indirection with a privacy invasive "Unique and Permanent" identifier
> which seems to be the only non-overlapping part of this work - in fact I only
> see downsides.
> 
> Cheers,
> S.
> 
> 
> >
> > --- 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