Subject: [Ideas] Privacy benefits of Identity Was: Re: Spencer Dawkins' Yes on charter-ietf-ideas-00-00: (with COMMENT)

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

On Wed, Sep 13, 2017 at 1:56 PM, Uma Chunduri <[email-masked]> wrote:
>         > Is a look at general security implications, in a form that specific
>         >framework  usages can point to, on the table for IDEAS?
>         >e
>         Spencer,
>
>         I believe there are two discrete components being championed in IDEAS:
>         One, is mapping system of identifier to locators and the other is introduction of identity mapping. The former looks much more like a routing or name resolution protocol, and the later would be doing identity management and possible collecting PII. There are obviously many security implications to      both parts, however I think the threats and sensitivity between these is quite different, i.e. hacking into the ID/loc mapping data base could result in misdirecting packets, hacking into identity store may result in loss of users' privacy.
>
> [Uma]: Tom, you summarized well. I would note there is interconnected aspect to these 2 items w.r.t security. Identity AUTH can inherently bring security (and if needed privacy) to Identifier/Location mapping and strengthen that area tremondoesly.

Uma,

I am still trying to understand exactly how identity improves user
privacy and doesn't hurt it. Item b. in section 2 of the identity use
case draft seems to be the most pertinent description. That reads:

"b.  Data plane anonymization allows entities to communicate
anonymously from the outside observers.  Identity provides
deanonymization for various data plane ephemeral Identifiers, if
required, and enables resolution of which entity is behind these
identifiers for legitimate users (entities itself in some cases)."

Data plane anonymization exists by virtue of providing a hosts
multiple addresses or identifiers and not putting anything in a
packets that allow cross correlation. Identity is not required to
achieve anonymization.

Per the text, identity provides for deanonymization which seems to
contradict the goal of anonymization. The text also states that
deanonymization would be done "if required". So my question is under
what circumstances would deanonymization be required?

Thanks,
Tom

---

From: Uma Chunduri <[email-masked]>
Date: Wed, 13 Sep 2017 23:23:30 +0000

>"b.  Data plane anonymization allows entities to communicate anonymously from the outside observers.  Identity provides deanonymization for various data plane ephemeral Identifiers, 
                >if required, and enables resolution of which entity is behind these identifiers for legitimate users (entities itself in some cases)."

	>Data plane anonymization exists by virtue of providing a hosts multiple addresses or identifiers and not putting anything in a packets that allow cross correlation. Identity is not required to achieve anonymization.
	>Per the text, identity provides for deanonymization which seems to contradict the goal of anonymization. The text also states that deanonymization would be done "if required". 

                >So my question is under what circumstances would deanonymization be required?

[Uma]: Great question.
It's possible,  in case if receiving entity of the data traffic want's to control which entities it wants to receive the traffic from (or prioritize them). 
A simple example could be a connected vehicular node/IoT may want to receive traffic from only certain entities (dealer or manufacturer or xyz)  updates and their long-lived ID's are 
used in the local policy at the receiving end. If one of the legit sending entity uses anonymized identifier; receiving entity might want to de-anonymize  the same before accepting the traffic -  to see if it matches to the corresponding long-lived Identifier it set the policy for.

This is one example for the description of section 2, point B you quoted.

Best Regards,
--
Uma C.

---

From: Tom Herbert <[email-masked]>
Date: Wed, 13 Sep 2017 16:53:11 -0700

Uma,

That implies addresses are used as security mechanism, but really
there's no security in addresses. They can too easily be spoofed. For
security, there's are already existing mechanisms for authentication
that are much stronger than any address verification.

As for the question about changing long lived identifiers, it seems
like that could be accomplished as a protocol between two endpoints.
For instance if endpoint A and endpoint B want to communicate they
could exchange a list of addresses they should consider to be
equivalent through a secure side channel. This doesn't require any
interaction with the network infrastructure other than getting
multiple address assignments. MP-TCP effectively allows this and is
even compatible with existing firewalls.

Thanks for the discussion,
Tom