Re: [secdir] secdir review of draft-ietf-6man-stable-privacy-addresses-16

[Vincent Roca <[e-mail]>]

Hello Fernando,

> Thanks so muh for your review! Please find my comments inline...
> 
> 
> On 01/21/2014 11:42 AM, Vincent Roca wrote:
>> 
>> The document discusses security and privacy aspects and there is little
>> to add.
>> I just have a couple of comments:
>> 
>> - It is said:
>>      MD5 [RFC1321] and SHA-1 [FIPS-SHS] are two possible options for F().
>> Although there is probably no harm in using MD5 in this context, it is
>> probably not appropriate to explicitely mention it as an alternative
>> given the known collision risks. Removing any reference to MD5 is
>> probably wiser. Adding SHA-256 also...
> 
> As you have correctly noted, MD5 is fine for this context. For instance,
> both RFC 6528 and RFC 6056 suggest the possible use of MD5 (and at the
> time we had this same exact discussion :-) ).
> 
> Note that we do not require any specific hash function, since the choice
> always  represents a tradeoff.

I understand all of this. But there's a desire to get rid of MD5!
I've just been through IESG records, and non surprisingly Stephen
made the same comment.


>> - The first bullet of Section 9 says:
>>      They prevent trivial host-tracking, since when a host moves from
>>      one network to another [...] the resulting Interface Identifier
>> will also change.
>> There are many ways to track a device (or even a user across multiple
>> devices),
>> e.g. in the Mobile OS context (Android, iOS...) that is one of
>> the targets of this
>> document. So the above claim should be clarified a little bit
>> IMHO, highlighting > the "trivial" idea.
> 
> Maybe tweak the text to "...trivial host-tracking based on the IPv6
> address"?

Agreed.


>> The benefits I see in having privacy preserving IPv6 addresses is that it
>> prevents an external attacker that analyzes flows captured in a backbone
>> from linking a given device traffic before/after moves (especially if
>> the flow is encrypted). But of course it won't prevent an advertising and analytics
>> company to track a device if some higher level ID is used.
> 
> Clearly, this document aims to mitigate just host-tracking that is
> enabled by IPv6 addressing. But, as you correctly note, there might be
> other vectors (for instance, an attacker could have malware installed on
> the node he wants to track). Note, however, that tracking based on IP
> addresses wasn't really possible for IPv4.. and that the aforementioned
> tracking could be performed by just some guy that happens to run e.g. a
> web site you usually connect to.
> 
> Thoughts?

Privacy preserving IPv6 addresses are important, clearly and I won't
question it. But there are so many tracking technics widely used
today (I don't know if you're familiar with smartphone tracking, but
you can have a look at: http://www.flurry.com/big-data.html
and this is only a subset of the visible part).
The difference I see is what I've mentioned: IPv6 address tracking
facilitates tracking within the core network, just by analyzing the outer
IP header, even if the content is encrypted. It's good to protect from
this attack.

BTW, I'm not suggesting that this discussion needs to be summarized
in the document.

Cheers,

   Vincent