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

Tom Herbert <tom@herbertland.com> Wed, 04 October 2017 17:07 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 360401342FC for <ideas@ietfa.amsl.com>; Wed, 4 Oct 2017 10:07:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, 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 NbqAHswJiMzM for <ideas@ietfa.amsl.com>; Wed, 4 Oct 2017 10:07:13 -0700 (PDT)
Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (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 605B013422B for <ideas@ietf.org>; Wed, 4 Oct 2017 10:07:13 -0700 (PDT)
Received: by mail-qt0-x22d.google.com with SMTP id a43so14577754qta.0 for <ideas@ietf.org>; Wed, 04 Oct 2017 10:07:13 -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:content-transfer-encoding; bh=qBfTepalzz5r4Xoc5udfew+r8ONZvBuvAUGWQaA4OF4=; b=HXr3BtTlH9VFX30pDN8CMgPScsZAmeAblPaDCkXzbJSa7VXMhXU1fSEpfhUmMFGOs+ 0q4gYV++bawcIXjte5v8Xnq7VSA1nlZIdeTMzVJGZU4n3fKrlS5NPuEfRsk07jWmkvdE vyR9eFCrlaTQc8Rkm9mfSnoPOXbiT+uS90O1lvEsthSy8PNHIXT+c2U4ToHAdVcpMlID wdYVqbWXV+x9ez1/F7edcTVSQEL1miPwdbWxV4X5zvBD23BELyMZtIZVaZcAzXpsHFWK +Ry0Xo40N4CFWT/BZu2ir/Fy9Kold6L5MspKBActKgMsfbCexCtrVw/oiSoP1Lv5n7tK lVpw==
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:content-transfer-encoding; bh=qBfTepalzz5r4Xoc5udfew+r8ONZvBuvAUGWQaA4OF4=; b=MR2PJ5HhoU4Fw78kDSpzt1Js7pOiVc5lpNyKgr9QdLlqJ1w8j2FsvaYsE5R4Mx18KF dxqLgavS7utEFCRWX6j74hfQ4xrFidNFnn+x0iw389XjvipcIVw4CWcYhhHsj3yVc1o+ 7D4F/Feys9Cc1A0i18vJ7fgQGgz4W/zoktraQeWYxz7fgB/irpJGPLt/MvhJsZQ19Byd 5/TdfP/jymSpMFrjdNLvs2KhP/OpJ5fjcO63XuQGIJxvAD5JbXw0pQa0ANqLCyMyKph0 pyH5QppIqK5acxPgD1ZbARUIwgfSTWuA4o+/uPxba196mrE0d9G3ffjmT0JJKwydXc2X 8dhg==
X-Gm-Message-State: AMCzsaVMfun++SXhM4YGBjCmqbkZH9j8a860XPncuNMkWqEkFZ1aTQXe 6sq7BDm56T0Iz82ah2J7O3h/ev0WjsETFykt4GZcxA==
X-Google-Smtp-Source: AOwi7QCDrJUz3Va4cxYW1t6CiVJf3uMVizWZqnZtSR94xFJ9FfTH2cvzLMNLeuSOVTUF67fex1TAW032UJdYDmMxDpY=
X-Received: by 10.200.35.247 with SMTP id r52mr30777788qtr.275.1507136832363; Wed, 04 Oct 2017 10:07:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.48.144 with HTTP; Wed, 4 Oct 2017 10:07:11 -0700 (PDT)
In-Reply-To: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie>
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>
From: Tom Herbert <tom@herbertland.com>
Date: Wed, 4 Oct 2017 10:07:11 -0700
Message-ID: <CALx6S36-24VWt==yCwE_u+52fehuGA2w-anDv95Oy6hw1vTzPw@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: ideas@ietf.org, IETF-Discussion <ietf@ietf.org>, Phillip Hallam-Baker <phill@hallambaker.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/KO0374xkbMMhMQmTijsy5fQPhxc>
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 17:07:19 -0000

On Wed, Oct 4, 2017 at 9:34 AM,  <stephen.farrell@cs.tcd.ie> wrote:
>
>
> 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.
>
Stephen,

There are two distinct efforts represented in IDEAS. One is a
developing a common identifier/locator mapping system and the other is
identity management. IMO the first is much more tangible and it's
clear this is needed given the emergence of id/loc use in data center,
mobile networks, as well as network virtualization. The identity
effort is less clear in terms of feasibility, privacy, and benefits--
there might be something there, but honestly it looks much more like a
research project to me at this point.

Tom