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

Tom Herbert <tom@herbertland.com> Wed, 04 October 2017 22:32 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 037DC1344E4 for <ideas@ietfa.amsl.com>; Wed, 4 Oct 2017 15:32:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.898
X-Spam-Level:
X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, URIBL_BLOCKED=0.001] 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 VYT4eIpx7ra1 for <ideas@ietfa.amsl.com>; Wed, 4 Oct 2017 15:32:16 -0700 (PDT)
Received: from mail-qt0-x22e.google.com (mail-qt0-x22e.google.com [IPv6:2607:f8b0:400d:c0d::22e]) (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 1493B134309 for <ideas@ietf.org>; Wed, 4 Oct 2017 15:32:12 -0700 (PDT)
Received: by mail-qt0-x22e.google.com with SMTP id f15so22200428qtf.7 for <ideas@ietf.org>; Wed, 04 Oct 2017 15:32:12 -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=GmLRG40ssy7uHv3JcSX13HnbRabUhvyF5sUWe8OuWeg=; b=Iuv2VnReC4DjvosrxUsn/+5pdg16rqTy7lSgYvKY3dAZorlHe36YIPFM4zqk9JIHiA UUfg2dzXJ1+YcEuB1CsvkFWw8FQ4TThg1laYFzFPsvl7ErcjUeBPPxOlRTMDXcT984Kh V5uESodZVcns6cuVh1IozieGV5bFO066QFjCOlPNXl7sATu3UdcgmTvV+fKmoENT5d/j SUTvbmVVW/cBW+L/pytEErxy8E5jt5hCKbsNKATQduiEA4ovVSUSF0qDBeHeRyKr6GHH yBfBj/H/q251J7dir42TY3GCivckao8Qzee5XUuNdMU0wne8P66CBIOtDvRf4vH28XKy 3oxw==
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=GmLRG40ssy7uHv3JcSX13HnbRabUhvyF5sUWe8OuWeg=; b=PbdTgO3yw7R2cQo3EU3W1UELSd3iPN8pw5eiemXROco7tt9PiQcVfKdE4qFD+f8LMS zMkbyKY4APif4s1kwHEWLWVTP920LoIGdt9/7IKeD2v2qpY0RxmBU6yYizM/WSiDWVbh ANgL/fXv2YtghbiOVHhlQcPzfhfo9LyDATYNURVmL4UZLWtWbIsJ8H3aKGmjBvKkOfdY T4U/0Edb3U1KwmCdZ8EFJIHAPy7CdiXSa6cCICiUA/WHajGEvzhjCzvMJD9nw+laNaDs m0M1cXVeMiffSS3NZNM63/M8yrh7Ky9F1jl1OFpU0PVZxQ7y5DLI5aitTdAXYytdAoy9 j/rg==
X-Gm-Message-State: AMCzsaWC2gg3gftvq83ltzLBKdvKLjse+vlizNr+Grda0iuTjIU9r088 CfLIBjc+jTQLVba2BGCN0kXvMdUpp9XcfmYl52JkvQ==
X-Google-Smtp-Source: AOwi7QB4x7CjBJpLzD44XhKYMoHGJd6AnZQoX8aFIPxP++KSZfv7g5Y8JW8rfmxr0GGBBcOd2umtC5rsyUXZPt3NXVI=
X-Received: by 10.200.36.164 with SMTP id s33mr17354343qts.108.1507156331879; Wed, 04 Oct 2017 15:32:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.144 with HTTP; Wed, 4 Oct 2017 15:32:11 -0700 (PDT)
Received: by 10.237.48.144 with HTTP; Wed, 4 Oct 2017 15:32:11 -0700 (PDT)
In-Reply-To: <CALx6S37X46993s0vg39TWbrELhhRBWYX4foXxHU2oipgc3pBQg@mail.gmail.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> <0BA14206-DC82-49EF-A625-B2425FA396F6@gmail.com> <CALx6S34CJtrF80B-f6Z3ZU16u8L4XdYvXJ+u_agTscF8yw0P0w@mail.gmail.com> <CALx6S37X46993s0vg39TWbrELhhRBWYX4foXxHU2oipgc3pBQg@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 4 Oct 2017 15:32:11 -0700
Message-ID: <CALx6S35Jyvx2G-fPLUbfSM=P=ykveBrDuq_hAuU-4LmmCA0MkQ@mail.gmail.com>
To: Dino Farinacci <farinacci@gmail.com>
Cc: lisp@ietf.org, ietf@ietf.org, Alexander Clemm <alexander.clemm@huawei.com>, Stephen Farrell <stephen.farrell@cs.tcd.ie>, "ideas@ietf.org" <ideas@ietf.org>, "phill@hallambaker.com" <phill@hallambaker.com>
Content-Type: multipart/alternative; boundary="001a11404e58c86f30055ac02d4e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/P9kDK_UjMETQ-3eytUmzpqMJeXc>
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:32:20 -0000

On Oct 4, 2017 1:35 PM, "Dino Farinacci" <farinacci@gmail.com> wrote:

Adding lisp@ietf.org to cc list.

How about creating a working group that solely focuses on deployment of a
mapping system and does not specify how and where identifiers are allocated?


+1

I suggest that could be called idloc (for Identifier-Locator)

Tom

I have made suggestions before that such a working group should be in the
ops area. Some examples include and are not limited to v6ops, dnsop, and
mboned.

Cheers,
Dino

> On Oct 4, 2017, at 12:45 PM, Stephen Farrell <stephen.farrell@cs.tcd.ie>
wrote:
>
>
> 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.)
>
> 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;-)
>
>> 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.)
>
>> 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...)
>
> 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;-)
>
>> 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.
>
>>
>> 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).
>
> 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
>
> _______________________________________________
> Ideas mailing list
> Ideas@ietf.org
> https://www.ietf.org/mailman/listinfo/ideas