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

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Oct 2017 13:35:32 -0700

Adding [email-masked] 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?

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

---

From: Stephen Farrell <[email-masked]>
Date: Wed, 4 Oct 2017 21:46:41 +0100

Hi Dino,

On 04/10/17 21:35, Dino Farinacci wrote:
> 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?
> 
> 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.

If there's deployment of things like LISP and HIP and folks
are interested in discussing/documenting what they've been
doing in the ops area then that seems quite reasonable sure.

S.

> Cheers, Dino
>> TL;DR - I am now even more convinced that this ought not go ahead.
>> (Sorry;-)
>> 
>>> There were a couple of things raised in the overall thread that
>>> I just wanted to quickly respond to:
>>> 
>>> 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.
>> 
>> 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
>> 
>> 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.
>> 
>>> 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.
>> 
>>> 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.
>> 
>> access to the GRIDS information would be better able to track
>> people compared to now.
>> 
>> 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 
>> Cheers, S.
>>>> [email-masked] Sent: Wednesday, October 04, 2017
>>>> 9:35 AM To: [email-masked] Cc: [email-masked]; 
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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.
>>>>>> 
>>>>>> 
>>>>>> * Names,  the signifier is the related to the signified by
>>>>>> a purely conventional relationship, (e.g. example.com to
>>>>>> its owner)
>>>>>> 
>>>>>> 
>>>>>> 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 
>>>>> 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 [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 5 Oct 2017 10:56:48 +1300

> 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 'GRIDS' tramples on previous work,
and 'identity' is a red flag. 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.

    Brian

> .

---

From: Tom Herbert <[email-masked]>
Date: Wed, 4 Oct 2017 15:32:11 -0700

On Oct 4, 2017 1:35 PM, "Dino Farinacci" <[email-masked]> wrote:

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?

+1

I suggest that could be called idloc (for Identifier-Locator)

Tom

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

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 4 Oct 2017 15:37:37 -0700

> I suggest that could be called idloc (for Identifier-Locator)

I would suggest ms-ops as in “mapping system operation”.

Dino

---

From: Robert Moskowitz <[email-masked]>
Date: Wed, 11 Oct 2017 10:56:48 -0400

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:
> 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,

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

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Oct 2017 09:15:56 -0700

On 10/11/2017 7:56 AM, Robert Moskowitz wrote:

> 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 am concerned that the current proponents of the IDEAS work are mainly
resisting the feedback, treating it as some roadblock put in the path of
their work by misguided privacy purists, and attempting to remove the
roadblocks by adding some weasel words to the charter. I would feel much
more confident if these proponents acknowledged the tension between
privacy and stable identifiers of any sort, if that tension was clearly
noted in the charter, and if privacy goals were clearly stated.

Specifically, I think there is a contradiction between some of
documents. For example, draft-padma-ideas-problem-statement-01 states that:

   o  A single entity may have multiple IDs, and IDs of the same entity
      may have different life spans that are different from the lifespan
      of the entity.  Furthermore, it is understood that IDs may have
      different lifecycles, which may be permanent or ephemeral by
      choice or design.

   o  Ephemeral (temporary) IDs may be used as a short-lived pseudonym
      for a permanent ID to protect the privacy of the related entity.

But then, draft-ccm-ideas-identity-use-cases-01 states that:

   a.  Unique and Permanent Identity representing the entity enables
       authentication (AUTH) with the mapping and Identity services
       infrastructure.  While it is possible to do AUTH on Identifiers
       those are not permanently associated to the entity.  Moreover,
       AUTH operation is a relatively an expensive and inefficient
       procedure (compared to LOC resolution for example) and can cause
       excessive startup delays for lot of applications.

The tension is obvious. On one hand, the ephemeral identifiers envisaged
in the problem statement would pretty much align the privacy properties
of the ID to those of IPv6 privacy addresses, and that's good. On the
other hand, the requirement to perform authentication on identities
completely negates that property.

I would be fine if the support for "Unique and Permanent Identity" was
explicitly excluded from the charter. There is obviously a need to
support some form of access control to a mapping database, but you do
not need a reference to a permanent identity for that -- systems similar
to CGA would work just fine.

-- 
Christian Huitema

---

From: Padma Pillay-Esnault <[email-masked]>
Date: Wed, 11 Oct 2017 10:32:44 -0700

On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema <[email-masked]>
wrote:

> 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.
>
>
> more confident if these proponents acknowledged the tension between privacy
> and stable identifiers of any sort, if that tension was clearly noted in
> the charter, and if privacy goals were clearly stated.
>
>
As one of the proponents, I feel I need to speak up because blanket
statements are just not helping.

Speaking on behalf of my fellow proponents, we have always welcomed
constructive feedback from people who want/can contribute and make the
technology better. We have been willing to clarify the charter
(clarification does not mean weaseling).

If it is helpful to  move forward, I am willing to volunteer for this work
and discuss with anyone to ensure constructive feedback and comments are
addressed.

Specifically, I think there is a contradiction between some of documents.
> For example, draft-padma-ideas-problem-statement-01 states that:
>
As said earlier this draft was not updated by the authors and a new version
was posted yesterday.

https://www.ietf.org/mail-archive/web/ideas/current/msg00520.html

> in the problem statement would pretty much align the privacy properties of
> the ID to those of IPv6 privacy addresses, and that's good. On the other
> hand, the requirement to perform authentication on identities completely
> negates that property.
>
> explicitly excluded from the charter.
>

AFAIK, none of the proponents resisted that.

> There is obviously a need to support some form of access control to a
> mapping database,
>

Agreed.

> but you do not need a reference to a permanent identity for that --
> systems similar to CGA would work just fine.
>

The identity of the device is just adding a lever of identifier which
effectively allows authentication to modify the identifiers used by that
device but also what the users of these identifiers can look up. If we had
used "user of identifier" it would have been misconstrued for humans. So
damn if you do and damn if you don't ...

We are open for discussions anytime.

Padma

> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>
>

---

From: Alexander Clemm <[email-masked]>
Date: Wed, 11 Oct 2017 18:47:52 +0000

Two additional thoughts inline, <ALEX>

From: Ideas [mailto:[email-masked]] On Behalf Of Padma Pillay-Esnault
Sent: Wednesday, October 11, 2017 10:33 AM
To: Christian Huitema <[email-masked]>
Cc: [email-masked]; [email-masked] list <[email-masked]>; Dino Farinacci <[email-masked]>; Robert Moskowitz <[email-masked]>; Brian E Carpenter <[email-masked]>; [email-masked]
Subject: Re: [Ideas] [lisp] WG Review: IDentity Enabled Networks (ideas)

On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema <[email-masked]<mailto:[email-masked]>> wrote:

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.

I am concerned that the current proponents of the IDEAS work are mainly resisting the feedback, treating it as some roadblock put in the path of their work by misguided privacy purists, and attempting to remove the roadblocks by adding some weasel words to the charter. I would feel much more confident if these proponents acknowledged the tension between privacy and stable identifiers of any sort, if that tension was clearly noted in the charter, and if privacy goals were clearly stated.

As one of the proponents, I feel I need to speak up because blanket statements are just not helping.

Speaking on behalf of my fellow proponents, we have always welcomed constructive feedback from people who want/can contribute and make the technology better. We have been willing to clarify the charter (clarification does not mean weaseling).

If it is helpful to  move forward, I am willing to volunteer for this work and discuss with anyone to ensure constructive feedback and comments are addressed.

<ALEX> +1 on welcoming constructive feedback.  To incorporate it we need to update documents.  An update to the ccm use case document was posted yesterday (rev -02) which incorporates a lot of the feedback given.  Clearly, this will not be the last update and other documents need to follow.
</ALEX>

Specifically, I think there is a contradiction between some of documents. For example, draft-padma-ideas-problem-statement-01 states that:

      choice or design.

As said earlier this draft was not updated by the authors and a new version was posted yesterday.

<ALEX> I think you meant to say it *was* updated ;-)
draft-padma-ideas-problem-statement will presumably be one of the documents that are next in line for updating.  </ALEX>

The tension is obvious. On one hand, the ephemeral identifiers envisaged in the problem statement would pretty much align the privacy properties of the ID to those of IPv6 privacy addresses, and that's good. On the other hand, the requirement to perform authentication on identities completely negates that property.

I would be fine if the support for "Unique and Permanent Identity" was explicitly excluded from the charter.

There is obviously a need to support some form of access control to a mapping database,

Agreed.

but you do not need a reference to a permanent identity for that -- systems similar to CGA would work just fine.

The identity of the device is just adding a lever of identifier which effectively allows authentication to modify the identifiers used by that device but also what the users of these identifiers can look up. If we had used "user of identifier" it would have been misconstrued for humans. So damn if you do and damn if you don't ...

Padma

--

Christian Huitema

_______________________________________________
lisp mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/lisp

---

From: Christian Huitema <[email-masked]>
Date: Wed, 11 Oct 2017 12:34:19 -0700

On 10/11/2017 10:32 AM, Padma Pillay-Esnault wrote:

>     but you do not need a reference to a permanent identity for that
>     -- systems similar to CGA would work just fine.
>
>  
>
> effectively allows authentication to modify the identifiers used by
> that device but also what the users of these identifiers can look up.
> If we had used "user of identifier" it would have been misconstrued
> for humans. So damn if you do and damn if you don't ... 
>

Some thing you should be hearing is that "long term identity of device"
has almost the same privacy properties as "long term identity of the
device's owner". You may think that identifying a random piece of
hardware is no big deal, but it turns out that the network activity and
network locations of that piece of hardware can be associated to those
of its human owner. So you need the same kind of protection for these
device identifiers as for human identifiers.

-- 
Christian Huitema

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 12:39:16 -0700

Let me ask for your opinion Christian (or anyone else for that matter). If a device is assigned a private/public key-pair and the identifier for the device is a hash of the public-key, is the identifier private?

Is the identifier trackable even when its network location is not generally known, not advertised publicly, and possibly changing frequently?

Dino

> On Oct 11, 2017, at 12:34 PM, Christian Huitema <[email-masked]> wrote:
> 
> Some thing you should be hearing is that "long term identity of device" has almost the same privacy properties as "long term identity of the device's owner". You may think that identifying a random piece of hardware is no big deal, but it turns out that the network activity and network locations of that piece of hardware can be associated to those of its human owner. So you need the same kind of protection for these device identifiers as for human identifiers.
> -- 
> Christian Huitema
>

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Oct 2017 12:43:46 -0700

On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <[email-masked]>
wrote:

> Let me ask for your opinion Christian (or anyone else for that matter). If
> a device is assigned a private/public key-pair and the identifier for the
> device is a hash of the public-key, is the identifier private?
>
>
I can't answer this in isolation. Does the identifier show up on the wire?
If so, then totally.

-Ekr

Is the identifier trackable even when its network location is not generally
> known, not advertised publicly, and possibly changing frequently?
>
> Dino
>
> device's owner". You may think that identifying a random piece of hardware
> is no big deal, but it turns out that the network activity and network
> locations of that piece of hardware can be associated to those of its human
> owner. So you need the same kind of protection for these device identifiers
> as for human identifiers.
> > --
> > Christian Huitema
> >
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 12:51:38 -0700

> On Wed, Oct 11, 2017 at 12:39 PM, Dino Farinacci <[email-masked]> wrote:
> I can't answer this in isolation. Does the identifier show up on the wire? If so, then totally.

When the payload is encrypted, it does not. So let me ask you these follow-up questions:

(1) If a host sources a packet with its identifier in one VM and an encapsulator in another VM (in the same physical system) encapsulates the packet but encrypts the payload before encapsulation, has the identifier remain private?

(2) If in (1), the packet is decapsulated by an intermmediate point, and then reencapsulated but the packet is encrypted with a new session key (from a new ECDH exchange) to the destination, has the identifier remained private?

Dino

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Oct 2017 12:57:55 -0700

On Wed, Oct 11, 2017 at 12:51 PM, Dino Farinacci <[email-masked]>
wrote:

> > Let me ask for your opinion Christian (or anyone else for that matter).
> If a device is assigned a private/public key-pair and the identifier for
> the device is a hash of the public-key, is the identifier private?
> >
> >
> When the payload is encrypted, it does not.

Are the handshakes that establish the cryptographic keys used to encrypt
the payload themselves encrypted? If it's IKE, the answer is probably yes,
but if not, I don't know.

So let me ask you these follow-up questions:
>
> (1) If a host sources a packet with its identifier in one VM and an
> encapsulator in another VM (in the same physical system) encapsulates the
> packet but encrypts the payload before encapsulation, has the identifier
> remain private?
>
> (2) If in (1), the packet is decapsulated by an intermmediate point, and
> then reencapsulated but the packet is encrypted with a new session key
> (from a new ECDH exchange) to the destination, has the identifier remained
> private?
>

Generally, I don't tend to think of things as being "private" or
"non-private". Rather we talk about who has a given capability or piece of
information. I think it's clear that in these cases the identifier was
available to the machine doing the deencapsulation/reencapsulation.
Obviously, that's worse for privacy than having it not have that
information. How much worse depends on a lot of factors.

In this particular, work, however, it seems like the privacy concerns are
about:

1. Whether the ID mapping systems reveal who is talking to who.
2. Whether this creates persistent identifiers that would otherwise be
destroyed when people changed their location

Maybe Christian and Stephen would like to say more about their concerns
-Ekr

>
> Dino
>
> >
> > -Ekr
> >
> >
> > Is the identifier trackable even when its network location is not
> generally known, not advertised publicly, and possibly changing frequently?
> >
> > Dino
> >
> > > Some thing you should be hearing is that "long term identity of
> device" has almost the same privacy properties as "long term identity of
> the device's owner". You may think that identifying a random piece of
> network locations of that piece of hardware can be associated to those of
> its human owner. So you need the same kind of protection for these device
> identifiers as for human identifiers.
> > > --
> > > Christian Huitema
> > >
> >
> >
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 13:13:07 -0700

> Are the handshakes that establish the cryptographic keys used to encrypt the payload themselves encrypted? If it's IKE, the answer is probably yes, but if not, I don't know.

For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) the Map-Request/Map-Reply exchange carry the EIDs in the clear. However, DTLS could be used but it would take more RTTs to get mappings in the encapsulator (causing more packet loss).

> Generally, I don't tend to think of things as being "private" or "non-private". Rather we talk about who has a given capability or piece of information. I think it's clear that in these cases the identifier was available to the machine doing the deencapsulation/reencapsulation. Obviously, that's worse for privacy than having it not have that information. How much worse depends on a lot of factors.

It needs the information for table lookups. So how private/trackable are IP addresses in packets today?

> In this particular, work, however, it seems like the privacy concerns are about:
> 

The charter talks about no designs or solutions. In LISP, the mappings are not revealed to the world, you need to sign Map-Registers (to make your network location available to others) and you need to sign Map-Requests (for retrieving network location).

And if you cannot get network location, you can't send packets (i.e. DoS) the destination or any nodes close to the destination (much better than what we have on the Internet today where anyone can send packets anywhere).

> 2. Whether this creates persistent identifiers that would otherwise be destroyed when people changed their location

We can solve this quite easily. I’ll use Bitcoin wallet addresses as an example. You can keep changing them for every transaction so there is no association analysis. We have a working group draft in the LISP WG that does just that.

> Maybe Christian and Stephen would like to say more about their concerns

Would welcome.

Dino

---

From: Eric Rescorla <[email-masked]>
Date: Wed, 11 Oct 2017 13:16:14 -0700

On Wed, Oct 11, 2017 at 1:13 PM, Dino Farinacci <[email-masked]> wrote:

> For SD-WAN implementations they use IKE. For RFC8061 (lisp-crypto) the
> Map-Request/Map-Reply exchange carry the EIDs in the clear. However, DTLS
> could be used but it would take more RTTs to get mappings in the
> encapsulator (causing more packet loss).
>

Uh really terrible? That's why things like Tor exist.

I'm not sure it's useful to continue with the technical side of the present
discussion. We're not trying to design a system here. The requirements for
the system the WG is to design is is properly the kind of question that
needs to be hashed out for the charter for the WG.

-Ekr

> The charter talks about no designs or solutions. In LISP, the mappings are
> not revealed to the world, you need to sign Map-Registers (to make your
> network location available to others) and you need to sign Map-Requests
> (for retrieving network location).
>
> And if you cannot get network location, you can't send packets (i.e. DoS)
> the destination or any nodes close to the destination (much better than
> what we have on the Internet today where anyone can send packets anywhere).
>
> We can solve this quite easily. I’ll use Bitcoin wallet addresses as an
> example. You can keep changing them for every transaction so there is no
> association analysis. We have a working group draft in the LISP WG that
> does just that.
>

---

From: Sam Sun <[email-masked]>
Date: Wed, 11 Oct 2017 16:50:21 -0400

I second Padma on this!

I suggest we all work more constructively in refining our charter here, 
and be more focused on the tasks listed in the charter. It's probably 
too early to fight on the exact meaning of any particular word (e.g. 
'identity'). Features like privacy protection and discoverability can 
also be left for discussion when we work on the details of the 
framework, instead of being used to kill the whole proposal.

By the way, statements like "someone else failed before" should never be 
a reason to stop working on something of such importance.

Sam

On 10/11/17 1:32 PM, Padma Pillay-Esnault wrote:
>
>
> On Wed, Oct 11, 2017 at 9:15 AM, Christian Huitema 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>>     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. 
>
>     I am concerned that the current proponents of the IDEAS work are
>     mainly resisting the feedback, treating it as some roadblock put
>     in the path of their work by misguided privacy purists, and
>     attempting to remove the roadblocks by adding some weasel words to
>     the charter. I would feel much more confident if these proponents
>     acknowledged the tension between privacy and stable identifiers of
>     any sort, if that tension was clearly noted in the charter, and if
>     privacy goals were clearly stated.
>
>
> If it is helpful to  move forward, I am willing to volunteer for this 
> work and discuss with anyone to ensure constructive feedback and 
> comments are addressed.
>
>
>     The tension is obvious. On one hand, the ephemeral identifiers
>     envisaged in the problem statement would pretty much align the
>     privacy properties of the ID to those of IPv6 privacy addresses,
>     and that's good. On the other hand, the requirement to perform
>     authentication on identities completely negates that property.
>
>     I would be fine if the support for "Unique and Permanent Identity"
>     was explicitly excluded from the charter.
>
>
>     [email-masked] <mailto:[email-masked]>
>     <https://www.ietf.org/mailman/listinfo/lisp>
>
>
>
>

---

From: Dino Farinacci <[email-masked]>
Date: Wed, 11 Oct 2017 14:25:27 -0700

> Uh really terrible? That's why things like Tor exist.

TOR exists because the network layer doesn’t have sufficient security. I’m preaching to the choir.

> I'm not sure it's useful to continue with the technical side of the present discussion. We're not trying 

It is useful because there is usually no technical discussion among people from different areas of expertise. The discussion tend to happen when a decision like this is made.

So I’ll take the discussion whenever I can get it!

> to design a system here. The requirements for the system the WG is to design is is properly the kind of question that needs to be hashed out for the charter for the WG.

I am trying to design a system. And we need more deployment experience. And I think an IETF working group can help facilitate this. Otherwise, people will do it else where and new protocols will surface OUTSIDE of the IETF. And that is when scale, security and interoperability is not priority. 

In the IETF, we are for the common good. 

Dino

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Oct 2017 12:15:17 +0900

> I am trying to design a system. And we need more deployment
> experience.  And I think an IETF working group can help facilitate
> this. Otherwise, people will do it else where and new protocols will
> surface OUTSIDE of the IETF.  And that is when scale, security and
> interoperability is not priority.

old threat which sounds too much of my way or the highway, or i'll take
my ball and go home.

either it is simple to deal with the privacy concerns in the charter
wording or the proposed wg is really not all that concerned with the
privacy issue.  if the latter is the case, then indeed, the ietf may not
be the best place to work on it.

randy