Last Call Review of draft-ietf-6man-stable-privacy-addresses-14
review-ietf-6man-stable-privacy-addresses-14-secdir-lc-roca-2014-01-23-00

Request Review of draft-ietf-6man-stable-privacy-addresses
Requested rev. no specific revision (document currently at 17)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2014-01-21
Requested 2013-10-25
Other Reviews Genart Last Call review of -06 by Ben Campbell (diff)
Genart Last Call review of -16 by Ben Campbell (diff)
Opsdir Last Call review of -16 by Tim Chown (diff)
Review State Completed
Reviewer Vincent Roca
Review review-ietf-6man-stable-privacy-addresses-14-secdir-lc-roca-2014-01-23
Posted at https://www.ietf.org/mail-archive/web/secdir/current/msg04525.html
Reviewed rev. 14 (document currently at 17)
Review result Has Nits
Draft last updated 2014-01-23
Review completed: 2014-01-23

Review
review-ietf-6man-stable-privacy-addresses-14-secdir-lc-roca-2014-01-23

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