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

Phillip Hallam-Baker <phill@hallambaker.com> Wed, 04 October 2017 14:57 UTC

Return-Path: <hallam@gmail.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 0728B132C2A; Wed, 4 Oct 2017 07:57:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.698
X-Spam-Level:
X-Spam-Status: No, score=-1.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.199, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 HjjoWzQfnEG3; Wed, 4 Oct 2017 07:57:23 -0700 (PDT)
Received: from mail-oi0-x22f.google.com (mail-oi0-x22f.google.com [IPv6:2607:f8b0:4003:c06::22f]) (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 D4957132697; Wed, 4 Oct 2017 07:57:22 -0700 (PDT)
Received: by mail-oi0-x22f.google.com with SMTP id q4so2373985oic.7; Wed, 04 Oct 2017 07:57:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=bb7WMcqoVqRyzvWeR9USiXxED/AidAjwpfp8Jn/D4aY=; b=qOYfnKK5O0Nx1eK0dYR1qVQCVlEchGb2fLULjMXyobjXm9EBXoaMTPqCVfED/5mSXu EC1XUJspIJj7RBP4O90o+dOS98wimhCwK2LoT4Yv8GXCp+Acp3EB8h1Q5A2vrbJyvbuf sLS26iQLUA1EHfg+ITlSRUJNmyk1vu0sIYPPVDbZvdbcSYvz+DjMqUw+lZJc8vkvryUt uM4a6n/zct3E9bv6dny3W4klTWFIW0mRTk2NJL5BZwo4eliukHZIA2lmNVPDJ3N9EAQw 55g4dQyfVkoG9ssglFjv0rn8UzZTQcYjf9I5lwEAVGOEzN4ckC7lryRjCYu7lrmpbsLG RHtA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=bb7WMcqoVqRyzvWeR9USiXxED/AidAjwpfp8Jn/D4aY=; b=DZbD0zA3oY1ZuWDIUf4rjt1TJ6MXTnzCYQoonBpKDrT69LDG9eXbnIC0eI7otF/Enm Ffeu0R0ULrjOfAjc8q1UROx0RMReh713+iVG5wu/SUbgY93mMZyx5yeFLiLp9GyaHhTe iVEL1kgtmsQNxz46wulbiBnz4CLvcOF1QsEOu5MkDT8IQ5wjthk9OUK136wmklM2AahY tteBheXFYVGG/cD9qNW51RzK038mycHiafnSLt8vOz+4uDOHpbGs3cRe9d3R+QuaR4+v FELxwwYdOnWgSi2KjtV1pnK/aQDvSefwhFuTipAIV2QF/DuJmW2pEyKNq0JHtPxYuYuR TNLw==
X-Gm-Message-State: AMCzsaVs8KU6nKocWKWwR29O5DHrZROSRloM+a1T3Pn9PqBJMXRhL9kK SXcrGvSbsOaiBiQqiMNpq7txoDOetevS05tMKAzHkg==
X-Google-Smtp-Source: AOwi7QDoG4DiO1RtqK+v397pdArzemaY10bDU5yqGmCQKO0zt+poJsadpZD3mCEi6Vb+x6Hfgg1qOHdVSz4uEzY1zfQ=
X-Received: by 10.157.13.67 with SMTP id 61mr5831192oti.162.1507129042023; Wed, 04 Oct 2017 07:57:22 -0700 (PDT)
MIME-Version: 1.0
Sender: hallam@gmail.com
Received: by 10.157.95.12 with HTTP; Wed, 4 Oct 2017 07:57:21 -0700 (PDT)
In-Reply-To: <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>
References: <150670160872.14128.2758037992338326085.idtracker@ietfa.amsl.com> <778d5504-ba4f-d418-7b20-356353bb0fb2@cs.tcd.ie>
From: Phillip Hallam-Baker <phill@hallambaker.com>
Date: Wed, 04 Oct 2017 10:57:21 -0400
X-Google-Sender-Auth: tr83UhDZWHj_DOo4e062dVXgp_c
Message-ID: <CAMm+Lwg61PGrcmu=-e8ciD6Q+XmEaWWDys4g2M657VOjWmaGcg@mail.gmail.com>
To: Stephen Farrell <stephen.farrell@cs.tcd.ie>
Cc: IETF-Discussion <ietf@ietf.org>, ideas@ietf.org
Content-Type: multipart/alternative; boundary="001a113711b02e4200055ab9d338"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/29GQVLfMN_RlECK6ZZoE9eBx81w>
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 14:57:25 -0000

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
<https://www.google.com/search?tbo=p&tbm=bks&q=inauthor:%22Winfried+N%C3%B6th%22>
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?


I wrote this for the ename workshop and I think it shows that some of the
goals stated can be solved:
http://www.prismproof.org/Documents/draft-hallambaker-sin.html

But this is what my names look like:

alice@example.com.mm--mb2gk-6duf5-ygyyl-jny5e-rwshz
https://mb2gk-6duf5-ygyyl-jny5e-rwshz.example.com/

They are both legal addresses fully compliant with the DNS etc specs. The
first won't resolve on the regular DNS, the second does but the embedded
security properties will only be enforced if the resolver understands the
mm-- prefix.


I can use these names to achieve content based routing of both static and
dynamic data. In the first case, the identifier is the fingerprint of the
content itself, in the second, the identifier is the fingerprint of a key
signing the content.