Subject: [apps-discuss] privacy in applications - anybody working in this area or interested?

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 6 Nov 2013 00:58:38 +0100

Hello,
We're looking for enhancing applications with privacy features by assigning
different Interface ID (IID) to them. We're looking for people who work on
privacy in applications. We have a presentation in v6ops tomorrow and we ask
the people who works in this area to contact us and if possible for them to
attend to our presentation "iid-lifetime". 
https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime

Thank you

-----------smile----------
Hosnieh
. success is a journey, not a destination..
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey

---

From: Scott Brim <[email-masked]>
Date: Tue, 5 Nov 2013 17:03:49 -0800

> https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime

Hosnieh,

You've opened up a multi-layer issue here. If each application gets a
separate IID, that could make privacy more difficult, in that it could be
easier to track and correlate the behavior of applications even with low
layer encryption. Your proposal could be okay if each application (or
session, actually) could request a new IID at an arbitrary time, and if
there were a general way for sessions to let each other know this was
happening, like multihomed transport.  Fun yet?

Scott

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 05 Nov 2013 17:54:53 -0800

On 11/5/13 5:03 PM, Scott Brim wrote:

 > separate IID, that could make privacy more difficult, in that it could
 > be easier to track and correlate the behavior of applications even with
 > low layer encryption. Your proposal could be okay if each application
 > (or session, actually) could request a new IID at an arbitrary time, and
 > if there were a general way for sessions to let each other know this was

Scott,

I'm not sure I understand.

An example of what Hosnieh and I have been talking about is an 
application (like a web browser) having some privacy-enhancing feature 
(such as incognito browsing sessions/tabs). In such a case it would seem 
to make sure to pick a different IPv6 IID for traffic originated due to 
the separate session.

But the user presumably would want to make it hard to link that traffic 
with other traffic from the box, hence a multihomed transport (which 
links multiple sessions together) would seem to be the opposite of what 
they'd expect.

Regards,
    Erik

---

From: SM <[email-masked]>
Date: Tue, 05 Nov 2013 21:20:12 -0800

Hi Hosnieh,
>https://tools.ietf.org/html/draft-rafiee-v6ops-iid-lifetime

If I understood correctly the problem is:

   "This is also gives this ability to attackers to obtain user's
    information by using simple approaches such as creating a fake
    website and use it as trap to find the user's IP addresses."

The proposed solution in the draft is to use a temporary Interface 
ID.  It mentions having a lifetime per application.  If I understood 
correctly the proposal introduces an application identifier.  How 
does the application identify itself to the lower layer when it needs 
to use an IPv6 address?

Regards,
-sm

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 6 Nov 2013 12:39:45 +0100

Hi,

> The proposed solution in the draft is to use a temporary Interface ID.  It
> mentions having a lifetime per application.  If I understood correctly the
> proposal introduces an application identifier.  How does the application
> identify itself to the lower layer when it needs to use an IPv6 address?

This is like an intermediate framework between network layer and application
layer. There is two possibilities. Firstly, the framework checks the current
available processes in the list of tasks and if any processes wants to use
internet it assigns a IID. Secondly, the application can trigger a function
to ask for an IID and it is transparent for it how this happen. But this is
actually implementation issue. I implemented the first option for Windows to
check the performance. The second option is easier since the application
calls the function and this application layer lifetime does not need to care
about the processes in the node.

Does it answer your concern?

Thanks,
-----------smile----------
Hosnieh

---

From: SM <[email-masked]>
Date: Wed, 06 Nov 2013 08:39:53 -0800

Hi Hosnieh,
>about the processes in the node.

Thanks, the above addresses my question.

There is a message about identifiers at 
http://www.ietf.org/mail-archive/web/ietf/current/msg83662.html  I 
like the suggestion to "start from first principles before thinking 
about solutions" and "what needs to be identified, and what 
characteristics does it have".

Regards,
-sm

---

From: Scott Brim <[email-masked]>
Date: Wed, 6 Nov 2013 09:08:27 -0800

On Tuesday, November 5, 2013, Erik Nordmark wrote:

> An example of what Hosnieh and I have been talking about is an application
> (like a web browser) having some privacy-enhancing feature (such as
> incognito browsing sessions/tabs). In such a case it would seem to make
> sure to pick a different IPv6 IID for traffic originated due to the
> separate session.
>
> with other traffic from the box, hence a multihomed transport (which links
> multiple sessions together) would seem to be the opposite of what they'd
> expect.
>
> Regards,
>    Erik
>

Hi Erik.

A new IID used for a specific activity would stick out.  A scanner would
definitely notice it - you wouldn't just slip it past - and would say
"there's something unusual here, I might benefit by paying closer
attention".   If it's in a /64 with other more normal use, the scanner
would look even closer for correlations.  I don't think this gives more
privacy, I think it attracts attention.

On the other hand if I could encrypt my content and use multiple IIDs
within a single session, that would make correlating a bit more difficult.
 This kind of agility requires a handshake between endpoints, along the
lines of SCTP CMT or MPTCP.

IMHO ... Scott

---

From: "Hosnieh Rafiee" <[email-masked]>
Date: Wed, 6 Nov 2013 18:50:06 +0100

Hi Scott,

attention".   If >it's in a /64 with other more normal use, the scanner

Let me give you an example. Consider a scenario where there are different
nodes in a network that use the same prefix. We want to focus on one of
these nodes. It is a fixed node in this network. Since IPv6 addresses are
public addresses, dissimilar to IPv4, the IPv6 address of this node is the
unique identity of this node. Actually this is the feature of IPv6 to allow
easy end-to-end communications. It's not popular in IPv6 to use NAT yet.
This is because the main purpose of NAT is to address the lack of available
IP addresses. This problem existed in IPv4 but we do not have this problem
in IPv6. However, later they also used NAT as a way of hiding the real IP
addresses of the node inside the network but as I explained, NAT is still
not popular in IPv6 because it is against its actual feature. 
So, this means our target nodes use one unique IP address which is its real
identity to access different resources on the internet. If one of this
websites is a bad guy's website, the node is now vulnerable to possible
privacy and security attacks. As you know the initial step to attack a node
in a network is recon the node. This gives the attacker an easy way of recon
this node. 
But now if the IID of this node changes, then the attacker will not have
this opportunity to attack this node. The attacker does not know how many
nodes available in the same subnet prefix. 
Now let me explain about the level of privacy that we provide for our nodes
if they apply our approach. It is actually about medium to high privacy. If
you want to have high privacy, that is true that you might want to use
encryption as well. But our purpose is to decrease the chance of node's
recon.

I guess it would be useful if you can attend in our presentation (remote or
in person).

within a single session, that would make correlating a bit more difficult.
 This kind of agility requires a handshake between endpoints, along the
?>lines of SCTP CMT or MPTCP.  

-----------smile----------
Hosnieh
… success is a journey, not a destination….
You cannot change your destination overnight, but you can change your
direction ... Focus on the journey

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 05 Nov 2013 17:51:56 -0800

Scott,

Regards,
    Erik

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 06 Nov 2013 13:12:59 -0800

> privacy, I think it attracts attention.

It wouldn't only be for that specific activity. Instead a host would 
have some number of IIDs (current draft has max 10 active IIDs) and 
different applications will use different ones. As an IID is safe to 
remove the host stack can create a new one. (And if we can provide some 
new APIs to the stack an application can have its different sessions use 
different IIDs.) All of that by default - without any specific activity.

The specific activity (specific session) would just pick a different IID 
than other activity, making it harder to link with other activities/IIDs.

As long as the /64 prefix is shared by a large number of users, then the 
about should improve the pseudonymity.

> within a single session, that would make correlating a bit more
> difficult.  This kind of agility requires a handshake between endpoints,
> along the lines of SCTP CMT or MPTCP.

Ah - now I understand the MPTCP reference.

Spreading the traffic over multiple paths will potentially make traffic 
analysis and capturing (to decrypt) content harder. But I don't think it 
is required.

    Erik

---

From: Scott Brim <[email-masked]>
Date: Wed, 6 Nov 2013 13:21:32 -0800

On Wednesday, November 6, 2013, Erik Nordmark wrote:

> It wouldn't only be for that specific activity. Instead a host would have
> some number of IIDs (current draft has max 10 active IIDs) and different
> applications will use different ones.

Just to be clear: use the same IID for all instances of a particular
application? I hope not :-)

> about should improve the pseudonymity.

I guess I was expecting the /64 to be shared by very few.  If the expected
situation is a large number of users, then I withdraw my concern.

> analysis and capturing (to decrypt) content harder. But I don't think it is
> required.
>

Well, I wasn't thinking of multiple paths - I was thinking of being able to
use multiple "addresses" even on a single path, as an obfuscation technique.

Thanks ... Scott