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

From: Toerless Eckert <[email-masked]>
Date: Wed, 1 Nov 2017 18:21:46 +0100

On Wed, Oct 11, 2017 at 12:34:19PM -0700, Christian Huitema 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.

Sure, but i don't think it can be generalized:

There will be more and more non-individually owned nodes in public and
corporate infrastructures where requirements will be quite different
from those derived from individual human privacy.

If lets say those long term identifiers do not provide good human
privacy protection but good communications security properties and
managed transpacency for regulators then they could still be a great
benefit for those class of nodes.

[rant]

Trying to get more privacy into network layer is like making
tobacco more organic. You can get buried in the organic section
of the graveyard after you die of lung cancer. Great success!

Aka: Where is the IETF on any warnings, architectures or recommendations
on the actual application layer:

"Inhaling of this web page / IoT device will expose your personal
 activities related to it, social security number and credit card
 information to a "trusted set" of 1000 collaborating web services
 companies of which 10 at least have already been fined several times
 for leaking your information - and then made even more money out of it"

(sorry, just can't get beyond the fact that equifax is not making
 money out of their leakage...)

Should come with every mayor web page and IoT device.

[/rant]

Venting aside, i'd actually love to understand better if/what IETF
does for privacy inside eg: a TLS payload, besides sipbrandy/dprive/perc ?

Cheers
    Toerless

> -- 
> Christian Huitema

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

---

From: Tom Herbert <[email-masked]>
Date: Thu, 2 Nov 2017 08:30:11 -0700

> from those derived from individual human privacy.
Toerless,

That maybe true, but personal devices, such as smart phones and cars
that are associated with individuals, are hardly going away anytime
soon. How addresses are assigned to these devices has a material
impact on individual privacy. Even right now there are two long
threads on v6ops right now that are delving precisely into privacy of
IPv6 addresses that may be relevant. This includes discussion about
CGNAT and efforts by some governments to illegalize it because the
privacy it gives is too strong for law enforcement.

> on the actual application layer:
Maybe there should be something like that. But, not unlike security,
if the goal is to derive a system with good privacy characteristics
then privacy should be considered at every layer including the
networking layer.

Tom

---

From: Toerless Eckert <[email-masked]>
Date: Fri, 3 Nov 2017 18:52:58 +0100

Thanks, Tom, inline

> privacy it gives is too strong for law enforcement.

Sure. All i was saying is that we should not dismiss solutions if they
do not help to improve privacy. It reminds me of the congestion control
principles and the fact that a lot of money is made with video in
controlled networks without congestion control. As in: "Sorry, we couldn't
build a great solution for sensor devices in manufacturing plants because
those solutions wouldn't pass the privacy bar".

I am not even aware if we have good characterizations of solutions
vs. privacy like IMHO we have for congestion control, but of course its
a more complex topic. (IMHO: lot more cases IMHO to distinguish).

That being said, i would of course love to see that we leverage IDEAs to
also create options that (could) enhance privacy, i just don't think that
we will make a lot of progress if we can not do this work in a WG but
if all the complex issues have to be resolved on pre-wg mailing lists before
even charters are accepted. This is part of whats wrong with the IETF
if i may say so.

For example, Christian contested that long lived identifiers help to
improve privacy (for device = individual case) and those arguments about
privacy had the IESG turn their opinions.

IMHO: The long-lived identifiers are meant to be functionally limited. You do
increase the bar of identifying an individual when you do this because the
web applications need to do more work to correlate application layer
information across multiple functional identifiers.

So, how & where do we even create a common understanding about the qualitative and
quantitative privacy benefits of technology options if not in a WG. Functional
identifiers just being one example. 

Even more fundamentally: If each individual application layer function requires
authentication via e.g.: government, google or facebook ID, and all those
web services are free to correlate their information in the backend, any
network layer privacy work is just like growing organic tobacco.

Which is why i really would like to know what the state of requirements/BCP etc.
is re. privacy at app layer in the IETF, because without that knowledge, i can
only define the privacy benefits of a network layer enhancement under the
ASSUMPTION of particular application behavior.

My impression of IETF policy is "you have to trust the web services
provider (not to share/correlate/abuse user/client information)" and in the
same breath "you can not trust the network service provider (to behave in the
same way)". Would love to get pointed to documents proving this impression to
be wrong. Especially the option that there can be network providers that
users may want to trust more than arbitrary web services providers should IMHO
be acknowledged. And thats definitely an option i think is worthwhile to build
solutions against. 

Cheers
    Toerless

---

From: Tom Herbert <[email-masked]>
Date: Sat, 4 Nov 2017 09:34:07 -0700

> ASSUMPTION of particular application behavior.
I don't think that's true. Privacy enhancements at the network layer
are needed to prevent inferences of PII by third party using just
network layer information that might be passively intercepted.
Knowledge of the application is not needed. In the base case scenario,
it should be impossible for a random intermediate node in the Internet
to determine who is communicating to whom (identity), where someone is
communicating from (location), and what they are saying (content).

> be acknowledged. And thats definitely an option i think is worthwhile to build
I doubt there's any IETF RFC or BCP stating whom were required to
trust as a MUST. Personally, I don't inherently trust web service
providers, network service providers, government, vendors, or really
anyone else involved in communications (including myself :-) ). Some
trust is needed out of necessity to do anything useful, but we should
always be searching for ways to further minimize that. A good example
is turning up the TLS on the Internet; this eliminated the need to
trust the network with our plaintext. I believe a similar thing will
happen with addressing, we'll figure out how to eliminate all PII from
addresses so that we don't have to trust the network to not be making
inferences that breaks privacy.

Tom

---

From: John C Klensin <[email-masked]>
Date: Sat, 04 Nov 2017 17:37:12 -0400

--On Saturday, November 4, 2017 09:34 -0700 Tom Herbert
<[email-masked]> wrote:

>...
> A good example
> is turning up the TLS on the Internet; this eliminated the
> need to trust the network with our plaintext. 

And, for many people, replaces it with the need to trust
firewall and security appliance providers who have concluded
that they need to intercept and decrypt traffic in order to
identify malware and other undesirable traffic.   At least in
principle, one does get to choose which vendor to trust and does
know (by virtue of having to install special certificates) which
vendor or provider is being trusted, but those options may not
be meaningful for typical users.

I worry with that example and several others that the IETF is
not adequately distinguishing between "increasing privacy" or
"preventing mass surveillance" on the one hand and forcing users
into a "who do your trust" or even "who does someone trust on
your behalf" shell game on the other.

best,
   john

---

From: Toerless Eckert <[email-masked]>
Date: Mon, 6 Nov 2017 21:01:45 +0100

> In the base case scenario,

As an individual i agree. An individual who needs to VPN
across his home gateway routers in different countries to get access to
entertainment options when being abroad. But then there are so many paychecks
people want to live off: 

There is a lot of "Internet" business riding on geo-location of locators
(for better or worse). So, when it comes to IESG review of proposed work,
how would a scheme be vetted wrt.  those business models ? 

If we would take this geo-location awareness away from the network layer,
i can already see how any web browser would become even more DRM encumbered,
reaching down into the system to also protect reading of GPS location, and
i have to run from my hotel room outside to the street to catch a GPS signal
to let me watch my movie. Like those pico-cells from ATT.

Likewise, service-provider want to have subscriber-IDs to be able to treat
traffic from multiple subscribers fairly because there is really no good way
to do this without an explicit subscriber-ID if you want real address
anonymity (whether its identifier or locators). And that requirement i actually
agree to as an individual even a lot more than the geoloc one.

IMHO we must as the IETF be a lot more flexibility with allowing different
requirements and business models, else we will just see ore and more
of the counter reaction nicely summarized in http://queue.acm.org/detail.cfm?id=1242499>

I like a well standardized and documented IETF solution that exposes
end-user data a lot more than the secret dealings at application level
that happen today. Especially when we could start thinking of how to
guarantee that we provide means for the end-user/app to device what to
present to whom and why.

> Knowledge of the application is not needed.

Right. I can make life for those third parties harder by introducing what
i called functional identifiers, where ultimately every type of interaction
you do uses a different identifier and can therefore at network layer
by passive observers not be correlated into a single identity. But introducing
that type of work into network layer makes only sense if we want to assume
that there is no correlation across multiple functions at the application
layer anyhow. That was the example.

> anyone else involved in communications (including myself :-) ).

+1

> Some trust is needed out of necessity to do anything useful, but we should
> always be searching for ways to further minimize that.

The more you want to do across the Internet, the more you need to trust
those web services providers with your data. The real challenge is create more transparency
in those web service providers to allow for more verification of what they do. 

And why the heck should i not be able to get better services from network service
providers ? What they would need to know for interesting services is so much
less than what app providers are collecting about me. Why would i oppose a
subscriber ID so a network service provider can provide fairness better ?

> trust the network with our plaintext.

The problem with TLS is that it is evolving in a way that will again lead to
a weapons race. For example the fact that 1.3 removed totally the option for
no-encryption. Therefore eliminating the option of apps who need observable,
authenticated traffic to rely on just TLS. Or the fact that it mandates
encryption of certs so you can not even authenticate the identify of a web
service (not the client). There are good reasons why you want to have this
profile, but there are also good reason why you want othre profiles, and those
get consistently shot down in the IETF. And thats bad politics.

> I believe a similar thing will

The VPN service providers to access netflix abroad are an interesting
data point in this battle. Obviously i need to trust them to keep my
identify "private". Netflix did recently block a lot of them. What would
happen if ever more subscriber would use SPs offering that type of
locators. Would the OOT provider like hulu/netflix wake up and relax
geo-locking  Or do we get the GPS geoloc as i fear ?

In any case: a) if we want to get more addressing privacy, it would be good
to discuss the expectable outcomes of that, and b) i can not see how
to create that privacy without putting more trust into some entities
(such as the access==VPN SP).

Cheers
    Toerless

-- 
---
[email-masked]