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@xxxxxxxx] On Behalf Of
>> stephen.farrell@xxxxxxxxx Sent: Wednesday, October 04, 2017 9:35
>> AM To: tom@xxxxxxxxxxxxxxx Cc: ideas@xxxxxxxx;
>> phill@xxxxxxxxxxxxxxx; ietf@xxxxxxxx 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@xxxxxxxxxxxxxxx> wrote:
>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell
>>>> <stephen.farrell@xxxxxxxxx> 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@xxxxxxxx https://www.ietf.org/mailman/listinfo/ideas
Attachment:
signature.asc
Description: OpenPGP digital signature