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

Vincent Roca <vincent.roca@inria.fr> Wed, 22 January 2014 07:52 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 [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1534D1A0379; Tue, 21 Jan 2014 23:52:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.085
X-Spam-Level:
X-Spam-Status: No, score=-7.085 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.535] 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 NWyfCTynGbkN; Tue, 21 Jan 2014 23:51:58 -0800 (PST)
Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by ietfa.amsl.com (Postfix) with ESMTP id 1EA7E1A0376; Tue, 21 Jan 2014 23:51:57 -0800 (PST)
X-IronPort-AV: E=Sophos;i="4.95,698,1384297200"; d="scan'208";a="45664414"
Received: from demeter.inrialpes.fr ([194.199.24.102]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/AES128-SHA; 22 Jan 2014 08:51:57 +0100
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Vincent Roca <vincent.roca@inria.fr>
In-Reply-To: <52DE8B8B.4030905@si6networks.com>
Date: Wed, 22 Jan 2014 08:51:56 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <643D6B3C-607D-416D-9D1F-A5CB0631BA52@inria.fr>
References: <9B3F20E5-7999-468D-8642-A9CAFA6C27DA@inria.fr> <52DE8B8B.4030905@si6networks.com>
To: Fernando Gont <fgont@si6networks.com>
X-Mailer: Apple Mail (2.1085)
Cc: secdir@ietf.org, IESG <iesg@ietf.org>, draft-ietf-6man-stable-privacy-addresses@tools.ietf.org
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: Wed, 22 Jan 2014 07:52:01 -0000

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