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

[Robert Moskowitz <[e-mail]>]

Just sqeezing in a couple more replies before the last days of the 
Holiday...

On 10/04/2017 05:56 PM, Brian E Carpenter wrote:
> On 05/10/2017 09:35, Dino Farinacci wrote:
>> Adding [e-mail] 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?
> That seems reasonable, well defined and relatively uncontentious.
>
> The current proposed charter leaves me a bit puzzled. Firstly I agree
> that the name 'IDEAS' is misleading,

And other wg's are not?  The IETF's desire for 'nice' names often 
results in names a little misleading.  Thus need to read the charter.  
Not that everyone who worked on the charter got what they wanted.  It is 
called compromise.

> and 'GRIDS' tramples on previous work,

Yeah, I did/dont like it.  But it is not my draft.

> and 'identity' is a red flag.

Whow there!  You were part of the Namespace Research Group?  I think?  I 
was and we we worked a lot on this and came to the conclusion that there 
could be no conclusion.  Not even a rough concensus, it seemed.

I have been using 'identity' to apply to things for 20 years. Pretty 
much ever since I started working with things.  Anyone that holds the 
position that 'identity' means we are talking only about people are 
allowing their thinking to be clouded.

So we use qualify our use of such terms.  That is why I called it a 
'Host Identity', then I was challenged as to what I was naming? Were you 
at the NL meeting the week before Oslo?  'Oh you are naming the stack'.  
ARGH!

enough history.

> But if we get past terminology distractions,
> where's the meat? All the interesting stuff is relegated to drafts or a
> wiki, and the output is a 'framework'. The IETF has a very mixed record
> with 'framework' documents.

The meat is what is missing in current ID/Loc technologies to realize 
the full potential.  Discovery. Some level of reversiblity. Strong 
access controls.

I plan on doing some real protocol work.  And some real implementation 
guidelines for protecting privacy.

Bob

>
>      Brian
>
>> 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 <[e-mail]> 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:[e-mail]] On Behalf Of
>>>>> [e-mail] Sent: Wednesday, October 04, 2017 9:35
>>>>> AM To: [e-mail] Cc: [e-mail];
>>>>> [e-mail]; [e-mail] 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
>>>>>> <[e-mail]> wrote:
>>>>>>> On Fri, Sep 29, 2017 at 2:31 PM, Stephen Farrell
>>>>>>> <[e-mail]> 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
>>>>> [e-mail] https://www.ietf.org/mailman/listinfo/ideas
>>> _______________________________________________
>>> Ideas mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/ideas
>> .
>>
>