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

From: Vincent Roca <[email-masked]>
Date: Tue, 21 Jan 2014 15:42:48 +0100

Hello,

I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG.  These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.

IMHO, the document is Almost ready.

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...

- 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.
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.

Cheers,

   Vincent

---

From: Fernando Gont <[email-masked]>
Date: Tue, 21 Jan 2014 12:00:27 -0300

Hi, Vincent,

Thanks so muh for your review! Please find my comments inline...

> 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.

> 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"?

> 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

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?

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Vincent Roca <[email-masked]>
Date: Wed, 22 Jan 2014 08:51:56 +0100

Hello Fernando,

> 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.

> Maybe tweak the text to "...trivial host-tracking based on the IPv6

Agreed.

> web site you usually connect to.

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