Subject: [icnrg] Name privacy not good enough in ICN? Well, HTTPS seems no better!

From: Orandom <[email-masked]>
Date: Sun, 9 Apr 2017 09:46:25 -0400

http://www.mjkranch.com/docs/CODASPY17_Kranch_Reed_IdentifyingHTTPSNetflix.pdf

___________________________
iDevice - please excuse typos.

---

From: Nikos Fotiou <[email-masked]>
Date: Mon, 10 Apr 2017 11:06:51 +0300

Therefore,  hiding names only is not enough.

On 9/4/2017 4:46 μμ, Orandom wrote:
> _______________________________________________
> icnrg mailing list
> [email-masked]
> https://www.irtf.org/mailman/listinfo/icnrg
>

---

From: "Trossen, Dirk" <[email-masked]>
Date: Thu, 13 Apr 2017 09:48:36 +0000

Privacy is an arms race - like many other such arms races, it can be balanced/decided only through policy, not technology.

---

From: Klaus Schneider <[email-masked]>
Date: Thu, 13 Apr 2017 12:26:56 -0700

> Privacy is an arms race - like many other such arms races, it can be balanced/decided only through policy, not technology.

This seems to me a very general statement and a very interesting topic; 
so may I ask for some clarification?

- Privacy is an arms race -- between which parties?

- What are examples of "many other such arms races"?

- Aren't there examples where a change in technology (like the invention 
of the Internet or of mobile phones) leads to a major change in privacy, 
regardless of policy?

Please not that I'm not an expert in privacy or security, which I think 
applies to many readers on this mailing list.

Best regards,
Klaus

---

From: "Ilya Moiseenko (ilmoisee)" <[email-masked]>
Date: Thu, 13 Apr 2017 19:42:06 +0000

- Privacy is an arms race -- between which parties?
1) Corporation vs corporation. Netflix competes with cable companies (video on demand offerings). It is important for web companies to prevent data mining and ad insertion in their content.  
2) Corporations vs Nation states.
3) Nation state vs. Nation state.
4) Corporations vs citizen.
5) Nation state vs. citizen.

What do you mean? Policy changes always follow the changes in the business environment, technological advances, etc.
Policy can certainly be applied to citizen, corporations, and government itself. If there is a functional government, of course. 

Ilya

    Best regards,
    Klaus

---

From: Klaus Schneider <[email-masked]>
Date: Thu, 13 Apr 2017 15:16:12 -0700

> Policy can certainly be applied to citizen, corporations, and government itself. If there is a functional government, of course.

I was referring to the original statement which I understood as "Privacy 
[...] can be balanced/decided only through policy, not technology."

My point was that policy is not the only thing that matters. NDN could 
have some positive impact on privacy that is not achievable by changing 
policies around current technology.

After re-reading the sentence, I realized that "it" could also refer to 
the arms race: "[The arms race] can be balanced/decided only through 
policy, not technology.", which would make more sense.

Best regards,
Klaus

---

From: "Ilya Moiseenko (ilmoisee)" <[email-masked]>
Date: Fri, 14 Apr 2017 00:58:44 +0000

I can’t agree with you. My opinion is that CICN/NDN/CCN will have a negative impact on privacy. Even if names are obfuscated, they still form a structure (e.g. name tree). In other words, ICN applications work with structured data unlike the unstructured ephemeral HTTPS/TCP/IP pipe. Structured data is always easier to analyze. 

Ilya

On 4/13/17, 3:16 PM, "Klaus Schneider" <[email-masked]> wrote:

    

    
    Best regards,
    Klaus

---

From: GTS <[email-masked]>
Date: Thu, 13 Apr 2017 21:48:16 -0700

FWIW, I agree with this sentiment.

However, I think that one clear case when CCN/NDN offer better privacy
than today's Internet is when a box  (e.g., a computer on a home 
network) acts purely as a consumer
and only issues interests, e.g., a user browses the web. In this 
setting, lack of source addresses in interests
is a privacy benefit. In particular, DoS-ing that box is hard. The 
moment that box starts producing content it
becomes subject to attacks.
Cheers,
Gene

---

From: Muhammad Hosain Abdollahi Sabet <[email-masked]>
Date: Fri, 14 Apr 2017 17:07:57 +0430

​
>
> Privacy is an arms race - like many other such arms races, it can be
> balanced/decided only through policy, not technology.

​Whether arms race or not, I this the same statement(only through policy,
not technology) can be said for other topics. The thing about technology
here, as far as I understand, is that whether the very ICN technologies
amplify risks which may lead to threats for privacy.

​Bests,
Sabet​

On Thu, Apr 13, 2017 at 2:18 PM, Trossen, Dirk <
[email-masked]> wrote:

> ​​
> Privacy is an arms race - like many other such arms races, it can be
> balanced/decided only through policy, not technology.
>

---

From: Luca Muscariello <[email-masked]>
Date: Fri, 14 Apr 2017 12:54:21 +0000

The paper Dave has just brought up to the list shows some data. And I think
 Dave's point was that privacy is more than just L3/L4 confidentiality. It
goes across all layers.

So the structure Ilya mentions had to be considered across all layers and
the paper exploits this structure which is intrinsic to the application.

Also when we talk about privacy, we include confidentiality and anonymity,
user protection and content protection. It is a lot of things and not all
of them are always required.
Also, privacy assumes that the parties can agree about the details, so that
in case of privacy violation, accountability can protect the user for
real.  It is a contract with accountability.
Privacy agreements with many web companies
seem weak in protecting from privacy violation.

 Currently the user has no  choice. This way or the highway.
I disable cookies and nothing works anymore.
I disable trackers and install ad blocker and I get half of the service or
no service.
No real guarantee that my personal data is safe.

Dirk is right and I interpret that in the following way: w/o real policy
with accountability the more fake privacy you put the more insecure the
network risks to be as many parties, including governments, will implement
everything is possible to get your privacy violated.

Take TLS, it is binary: 100% confidentiality or 0% confidentiality because
of mad in the middle techniques as most enterprises do.

ICN or no ICN is not the point, IMO.

Luca

On Fri, 14 Apr 2017 at 06:48, GTS <[email-masked]> wrote:

> than today's Internet is when a box  (e.g., a computer on a home network)
> acts purely as a consumer
> and only issues interests, e.g., a user browses the web. In this setting,
> lack of source addresses in interests
> is a privacy benefit. In particular, DoS-ing that box is hard. The moment
> that box starts producing content it
> On 4/13/17, 3:16 PM, "Klaus Schneider" <[email-masked]> <[email-masked]> wrote:
>
>
>
>     > On 4/13/17, 12:26 PM, "icnrg on behalf of Klaus Schneider" <[email-masked] on behalf of [email-masked]> <[email-masked]@cs.arizona.edu> wrote:
>     >
>     >     > From: icnrg [mailto:[email-masked] <[email-masked]>] On Behalf Of Nikos Fotiou
> icnrg mailing [email-masked]://www.irtf.org/mailman/listinfo/icnrg
>
>

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 14 Apr 2017 07:49:04 -0700

On 13 Apr 2017, at 17:58, Ilya Moiseenko (ilmoisee) wrote:

> I can’t agree with you. My opinion is that CICN/NDN/CCN will have a 
> negative impact on privacy. Even if names are obfuscated, they still 
> form a structure (e.g. name tree). In other words, ICN applications 
> work with structured data unlike the unstructured ephemeral 
> HTTPS/TCP/IP pipe. Structured data is always easier to analyze.

Yes, I agree. CICN will always be worse than the modern HTTP+TLS+TCP+IP 
stack in this respect since it requires application structure at the 
lowest layer.

Best,
Chris

>     > On 4/13/17, 12:26 PM, "icnrg on behalf of Klaus Schneider" 
> <[email-masked] on behalf of [email-masked]> wrote:
>     >
>     >     > Privacy is an arms race - like many other such arms races, 
> it can be balanced/decided only through policy, not technology.
>     >
>     > 1) Corporation vs corporation. Netflix competes with cable 
> companies (video on demand offerings). It is important for web 
> companies to prevent data mining and ad insertion in their content.
>     > What do you mean? Policy changes always follow the changes in 
> the business environment, technological advances, etc.
>     > Policy can certainly be applied to citizen, corporations, and 
> government itself. If there is a functional government, of course.
>
>     >     > Privacy is an arms race - like many other such arms races, 
> it can be balanced/decided only through policy, not technology.
>     >     >

---

From: "Christopher Wood" <[email-masked]>
Date: Fri, 14 Apr 2017 07:55:48 -0700

>  Dave's point was that privacy is more than just L3/L4 

I agree.

> user protection and content protection.

In general, yes, the term is incredibly overloaded. However, we can 
(should) tease out different types of privacy with respect to different 
entities that are worth considering. See, e.g., 
http://sprout.ics.uci.edu/pubs/ccn-privacy.pdf.

> It is a lot of things and not all

This may be true of TLS 1.2, but it will not be true once TLS 1.3 hits 
mainstream. The goal of which is to disallow enterprise middleboxes from 
eavesdropping on traffic.

Best,
Chris

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 14 Apr 2017 17:41:53 +0000

IMO, the privacy issue begins with what users are comfortable with right now, and it can't be worse than the current situation. With ICN we talk about names of content, app./services, network, devices. For a consumer it is the first two named resources that matters. Today users are OK to expose the service-id they are accessing which is exposed to the network through DNS and IP addresses, but with CCN/NDN we go towards content IDs, which is the more sensitive part, one which is OK as long as the user is bound to trusted domains; but once third parties are involved it will overthrow any possibility of a general Internetworking based on ICN. So the solutions has to evolve in a way that makes the consumer feel unexploited, which is no worse than the case today, i.e. look for content-ID based networking in trusted spaces, but switch to service-IDs once it crosses the trust boundaries.

Regards,
Ravi

-----Original Message-----
From: icnrg [mailto:[email-masked]] On Behalf Of Ilya Moiseenko (ilmoisee)
Sent: Thursday, April 13, 2017 5:59 PM
To: Klaus Schneider <[email-masked]>; Trossen, Dirk <[email-masked]>; Nikos Fotiou <[email-masked]>; [email-masked]
Subject: Re: [icnrg] Name privacy not good enough in ICN? Well, HTTPS seems no better!

Ilya

    

    
    
    Best regards,
    Klaus

---

From: Luca Muscariello <[email-masked]>
Date: Fri, 14 Apr 2017 19:19:34 +0000

I don't think TLS1.3 is going to fix enterprise proxy MiM.

https://bto.bluecoat.com/news/industry-adoption-tls-1.3

The end user does not own the device and
it is not considered a privacy violation to stop an employee to do so
something that is out of the enterprise policy.

It becomes an arms race for real as the trick will happen no matter what
technology allows you to do as the policy is enforced in a different place
than where the technology pretends to fix the issue.

The employer can forbid to install a given browser, can change root
certificates etc etc.

The only real solution would be outside of technology by regulation. So
that detection of privacy violation, in a given case, not al cases, allows
the victim to sue all responsible parties.

---

From: Christopher Wood <[email-masked]>
Date: Fri, 14 Apr 2017 12:22:59 -0700

My point was that if TLS 1.3 is used, middlebox introspection isn't possible. Yes, the enterprise can (stupidly) restrict TLS 1.3 via policy if it so chooses. FWIW: I do not care much about enterprise networks. To me, privacy is more important out in the wild.

Best,
Chris

On Apr 14, 2017, 12:19 PM -0700, Luca Muscariello <[email-masked]>, wrote:
> it is not considered a privacy violation to stop an employee to do so something that is out of the enterprise policy.
>
> It becomes an arms race for real as the trick will happen no matter what technology allows you to do as the policy is enforced in a different place than where the technology pretends to fix the issue.
>
> The employer can forbid to install a given browser, can change root certificates etc etc.
>
> The only real solution would be outside of technology by regulation. So that detection of privacy violation, in a given case, not al cases, allows the victim to sue all responsible parties.
>
>
>
>
>
>
>
> On Fri, 14 Apr 2017 at 16:55, Christopher Wood <[email-masked] (mailto:[email-masked])> wrote:

---

From: Luca Muscariello <[email-masked]>
Date: Fri, 14 Apr 2017 20:11:11 +0000

This would require to define precisely:

"What users are confortable with right now."

Who has asked users? Do they care about TLS or if the web service encrypts
their password or if metadata is stored when they drive, read emails, buy
stuff?

IMO, the  user wants an insurance that is triggered when something bad
happens. The user wants to be protected against violations.
Only justice in democracy can provide that and contracts and regulation.
(There are countries where encryption  is forbidden by the law.)

About anonymity, it is up to the producer to provide that. And back to the
paper Dave brought up, anonymity is not something you can provide with non
ephemeral identifiers, right, but not even an opaque pipe can do that.
Fingerprints and classification can be obtained by exploiting recurrent
patterns and this goes way beyond L3/L4 anonymity.

On Fri, 14 Apr 2017 at 19:42, Ravi Ravindran <[email-masked]>
wrote:

> IMO, the privacy issue begins with what users are comfortable with right
> now, and it can't be worse than the current situation. With ICN we talk
> about names of content, app./services, network, devices. For a consumer it
> is the first two named resources that matters. Today users are OK to expose
> the service-id they are accessing which is exposed to the network through
> DNS and IP addresses, but with CCN/NDN we go towards content IDs, which is
> the more sensitive part, one which is OK as long as the user is bound to
> trusted domains; but once third parties are involved it will overthrow any
> possibility of a general Internetworking based on ICN. So the solutions has
> to evolve in a way that makes the consumer feel unexploited, which is no
> worse than the case today, i.e. look for content-ID based networking in
> trusted spaces, but switch to service-IDs once it crosses the trust
> boundaries.
>
> Regards,
> Ravi
>
> To: Klaus Schneider <[email-masked]>; Trossen, Dirk
> <[email-masked]>; Nikos Fotiou <[email-masked]>;
> [email-masked]
> negative impact on privacy. Even if names are obfuscated, they still form a
> structure (e.g. name tree). In other words, ICN applications work with
> structured data unlike the unstructured ephemeral HTTPS/TCP/IP pipe.
> Structured data is always easier to analyze.
>
> Ilya
>
>     > On 4/13/17, 12:26 PM, "icnrg on behalf of Klaus Schneider" <
> [email-masked] on behalf of [email-masked]> wrote:
>     >
>     >     > Privacy is an arms race - like many other such arms races, it
> can be balanced/decided only through policy, not technology.
>     >
>     > 1) Corporation vs corporation. Netflix competes with cable companies
> (video on demand offerings). It is important for web companies to prevent
> data mining and ad insertion in their content.
>     > What do you mean? Policy changes always follow the changes in the
> business environment, technological advances, etc.
>     >     > Privacy is an arms race - like many other such arms races, it
> can be balanced/decided only through policy, not technology.
>     >     >

---

From: Ravi Ravindran <[email-masked]>
Date: Fri, 14 Apr 2017 20:39:02 +0000

-          this is the implicit or explicit agreement one has with the service provider. If an operator sells me a pipe, he is not expected to see my application level transactions, on the other hand if he is an application service provider, there is some agreement that he trusts the enterprise to provide privacy guarantees. Of course, there are violations of this in today’s network, but I guess the stake holders know their boundary, or it spill out as legal issues.

-          So with ICN, if you have a network provider who is both a content and connectivity provider, ICN would be a straight fit, google is a good example here. But if the content request/delivery paths go through domains they don’t trust, that becomes an issue both for the consumer and the producers. Again the IDs you have in these requests matter, so the comment below on content-IDs versus service-IDs.

Regards,
Ravi

From: Luca Muscariello [mailto:[email-masked]]
Sent: Friday, April 14, 2017 1:11 PM
To: Ilya Moiseenko (ilmoisee) <[email-masked]>; Klaus Schneider <[email-masked]>; Nikos Fotiou <[email-masked]>; Ravi Ravindran <[email-masked]>; Trossen, Dirk <[email-masked]>; [email-masked]
Subject: Re: [icnrg] Name privacy not good enough in ICN? Well, HTTPS seems no better!

Who has asked users? Do they care about TLS or if the web service encrypts their password or if metadata is stored when they drive, read emails, buy stuff?

IMO, the  user wants an insurance that is triggered when something bad happens. The user wants to be protected against violations.
Only justice in democracy can provide that and contracts and regulation.
(There are countries where encryption  is forbidden by the law.)

About anonymity, it is up to the producer to provide that. And back to the paper Dave brought up, anonymity is not something you can provide with non ephemeral identifiers, right, but not even an opaque pipe can do that. Fingerprints and classification can be obtained by exploiting recurrent patterns and this goes way beyond L3/L4 anonymity.

On Fri, 14 Apr 2017 at 19:42, Ravi Ravindran <[email-masked]<mailto:[email-masked]>> wrote:
IMO, the privacy issue begins with what users are comfortable with right now, and it can't be worse than the current situation. With ICN we talk about names of content, app./services, network, devices. For a consumer it is the first two named resources that matters. Today users are OK to expose the service-id they are accessing which is exposed to the network through DNS and IP addresses, but with CCN/NDN we go towards content IDs, which is the more sensitive part, one which is OK as long as the user is bound to trusted domains; but once third parties are involved it will overthrow any possibility of a general Internetworking based on ICN. So the solutions has to evolve in a way that makes the consumer feel unexploited, which is no worse than the case today, i.e. look for content-ID based networking in trusted spaces, but switch to service-IDs once it crosses the trust boundaries.

Regards,
Ravi

-----Original Message-----
From: icnrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Ilya Moiseenko (ilmoisee)
Sent: Thursday, April 13, 2017 5:59 PM
To: Klaus Schneider <[email-masked]<mailto:[email-masked]>>; Trossen, Dirk <[email-masked]<mailto:[email-masked]>>; Nikos Fotiou <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [icnrg] Name privacy not good enough in ICN? Well, HTTPS seems no better!

Ilya

On 4/13/17, 3:16 PM, "Klaus Schneider" <[email-masked]<mailto:[email-masked]>> wrote:

    On 04/13/2017 12:42 PM, Ilya Moiseenko (ilmoisee) wrote:
    >
    > On 4/13/17, 12:26 PM, "icnrg on behalf of Klaus Schneider" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:
    >

    Best regards,
    Klaus

    >     > From: icnrg [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Nikos Fotiou
    >     > To: [email-masked]<mailto:[email-masked]>
    >     >> [email-masked]<mailto:[email-masked]>
    >     > [email-masked]<mailto:[email-masked]>
    >     > [email-masked]<mailto:[email-masked]>
    >     [email-masked]<mailto:[email-masked]>

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

---

From: Klaus Schneider <[email-masked]>
Date: Sun, 16 Apr 2017 13:38:43 -0700

On 04/14/2017 12:19 PM, Luca Muscariello wrote:
> technology allows you to do as the policy is enforced in a different
> place than where the technology pretends to fix the issue.
>
> that detection of privacy violation, in a given case, not al cases,
> allows the victim to sue all responsible parties.

Or by the individual leaving the company and joining one that doesn't 
violate their privacy that much.

I think the current situation shows that employees are willing to trade 
off their privacy against a higher salary or other benefits.

Best regards,
Klaus

>
>
>
>
>
>
>
> On Fri, 14 Apr 2017 at 16:55, Christopher Wood
> <[email-masked] <mailto:[email-masked]>> wrote:
>

---

From: Luca Muscariello <[email-masked]>
Date: Mon, 17 Apr 2017 12:25:42 +0000

Nobody gets paid more for accepting privacy violations. If it is privacy
violation.

Enterprises use proxies for security reasons, detect malwares, intrusions
etc.

Schools to avoid kids to visit bad websites etc...

Privacy violations within enterprises are regulated by law depending on the
country.

If my private data is stolen while stored in a web service either I am
never told, or I just get a notification to change my passwords.

IMO the real problem is trust more than privacy because privacy is just
impossible to implement. Those who pretend to sell privacy are selling
something else.

On Sun, 16 Apr 2017 at 22:38, Klaus Schneider <[email-masked]> wrote:

> >     > The paper Dave has just brought up to the list shows some data.
> And I
> >     > think
> >     > So the structure Ilya mentions had to be considered across all
> layers
> >     > and
> >     > Also, privacy assumes that the parties can agree about the
> details, so
> >     > that

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 17 Apr 2017 16:05:05 +0100

> impossible to implement. Those who pretend to sell privacy are selling

That's overblown nonsense. In my experience abuses of the
(useless when not qualified) term "trust" far outnumber
attempts to mis-sell privacy. But then an awful lot of
this thread seems to be pure opinion with no evidence
offered, so I guess that's par for the course;-)

As to the original post: yes traffic analysis is a way to
attack HTTPS. As it happens we've defined new ways in which
padding can be done in TLS1.3 and in h2, so I'd expect that
traffic analysis will get harder over time as we learn how
to use those new protocol features and as wiser application
layer developers consider TA as part of their threat model.

If ICN aims to try to replace some of that HTTPS traffic then
it'd need to be at least no worse. I'm not sure if that will
or will not turn out to be the case myself.

Cheers,
S.

---

From: Christopher Wood <[email-masked]>
Date: Mon, 17 Apr 2017 08:25:21 -0700

> or will not turn out to be the case myself.

+1.

Best,
Chris