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

stephen.farrell@cs.tcd.ie Wed, 04 October 2017 16:34 UTC

Return-Path: <stephen.farrell@cs.tcd.ie>
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 69CCA13430D; Wed, 4 Oct 2017 09:34:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.3
X-Spam-Level:
X-Spam-Status: No, score=-4.3 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie
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 wbDeFHxQCQwt; Wed, 4 Oct 2017 09:34:47 -0700 (PDT)
Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 185B313422B; Wed, 4 Oct 2017 09:34:46 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 9EC68BE2F; Wed, 4 Oct 2017 17:34:44 +0100 (IST)
X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie
Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UK2JXrI6b8Pz; Wed, 4 Oct 2017 17:34:43 +0100 (IST)
Received: from [127.0.0.1] (unknown [109.125.18.168]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 213F9BE24; Wed, 4 Oct 2017 17:34:43 +0100 (IST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1507134883; bh=0yVzGYDz/5tCmZwcdjkqWw6Ofv5t1sQDEtQqbpK7/Ws=; h=To:Cc:From:Subject:In-Reply-To:References:Date:From; b=xTyTL0HREOEFSk0cyl5nCFw2PqcyV/mWptY6V1EFtncPHO9ZOgn6MPbuWoFzBfxNi o3QXWoD5jzjRXL5gxyowRoFtmkAy9ovvJioDRlWtjuO5nm1L3ke9Wj6S8NsrW6tkam jqrgJ5albIoRv1blVjGn/xQfnxceUZk5QRt8VfZs=
X-Priority: 3
To: tom@herbertland.com
Cc: ideas@ietf.org, ietf@ietf.org, phill@hallambaker.com
From: stephen.farrell@cs.tcd.ie
In-Reply-To: <CALx6S370-TuoUicWep5vV2NjLPS4d-HP1qVxW_nGrxhBLw6Eug@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>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
Date: Wed, 04 Oct 2017 16:34:41 +0000
Message-ID: <8kd5pq.oxb4pv.rtlo8t-qmf@mercury.scss.tcd.ie>
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/9EwY1vQu0Exy5bdC1ca_dugXiTY>
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 16:34:49 -0000


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
>