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

Vincent Roca <vincent.roca@inria.fr> Tue, 21 January 2014 14:42 UTC

Return-Path: <vincent.roca@inria.fr>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 5136A1A0161; Tue, 21 Jan 2014 06:42:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.084
X-Spam-Status: No, score=-7.084 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id s_Jul-HXNyGA; Tue, 21 Jan 2014 06:42:55 -0800 (PST)
Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr []) by ietfa.amsl.com (Postfix) with ESMTP id D426B1A014C; Tue, 21 Jan 2014 06:42:54 -0800 (PST)
X-IronPort-AV: E=Sophos; i="4.95,696,1384297200"; d="scan'208,217"; a="54207257"
Received: from eduroam-057014.grenet.fr ([]) by mail2-relais-roc.national.inria.fr with ESMTP/TLS/AES128-SHA; 21 Jan 2014 15:42:54 +0100
From: Vincent Roca <vincent.roca@inria.fr>
Content-Type: multipart/alternative; boundary="Apple-Mail-60--308692148"
Date: Tue, 21 Jan 2014 15:42:48 +0100
Message-Id: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr>
To: IESG <iesg@ietf.org>, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, secdir@ietf.org
Mime-Version: 1.0 (Apple Message framework v1085)
X-Mailer: Apple Mail (2.1085)
Subject: [secdir] secdir review of draft-ietf-6man-stable-privacy-addresses-16
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir/>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Jan 2014 14:42:57 -0000


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.