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

Fernando Gont <fgont@si6networks.com> Tue, 21 January 2014 16:00 UTC

Return-Path: <fgont@si6networks.com>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 354E31A0347; Tue, 21 Jan 2014 08:00:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXdmOZycTiyw; Tue, 21 Jan 2014 08:00:56 -0800 (PST)
Received: from web01.jbserver.net (web01.jbserver.net [IPv6:2a00:d10:2000:e::3]) by ietfa.amsl.com (Postfix) with ESMTP id D296C1A01C0; Tue, 21 Jan 2014 08:00:50 -0800 (PST)
Received: from 75-138-17-190.fibertel.com.ar ([190.17.138.75] helo=[192.168.3.102]) by web01.jbserver.net with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.82) (envelope-from <fgont@si6networks.com>) id 1W5dkr-00076C-W9; Tue, 21 Jan 2014 17:00:47 +0100
Message-ID: <52DE8B8B.4030905@si6networks.com>
Date: Tue, 21 Jan 2014 12:00:27 -0300
From: Fernando Gont <fgont@si6networks.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0
MIME-Version: 1.0
To: Vincent Roca <vincent.roca@inria.fr>, IESG <iesg@ietf.org>, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org, secdir@ietf.org
References: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr>
In-Reply-To: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: Re: [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 16:00:58 -0000

Hi, Vincent,

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.



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


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

Thanks!

Best regards,
-- 
Fernando Gont
SI6 Networks
e-mail: fgont@si6networks.com
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492