Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03

Tomek Mrugalski <tomasz.mrugalski@gmail.com> Mon, 15 February 2016 20:45 UTC

Return-Path: <tomasz.mrugalski@gmail.com>
X-Original-To: gen-art@ietfa.amsl.com
Delivered-To: gen-art@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 472151A898A; Mon, 15 Feb 2016 12:45:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.6
X-Spam-Level:
X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=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 BCZWsXjPxwor; Mon, 15 Feb 2016 12:45:49 -0800 (PST)
Received: from mail-lb0-x22e.google.com (mail-lb0-x22e.google.com [IPv6:2a00:1450:4010:c04::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E09EC1B29A5; Mon, 15 Feb 2016 12:45:48 -0800 (PST)
Received: by mail-lb0-x22e.google.com with SMTP id x1so5837386lbj.3; Mon, 15 Feb 2016 12:45:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=uJN0xpXpWUZ1Ey7Vk6xenPkRJ+Cp0xBhSJXMca3wj7g=; b=Y513C4Js0zcQLym3ROXZOhbg1POjvbYdCH8sUO3deNMFQ28MAduAtmYxJIpvUtw7Mx rES2jjh6Vo9SmioZaa6orRJmGlybaSCC1HCvpGO/AgHfE9/8FtA8hFqFfNi7HriYS0HC d7hbZmIgib43J1w+M0ixWBe4AD+789d2NHv5Zs3x3uEVy0LUIZCy0YLZFW05Jv5uYoFx qDUKHk2oepY6JXyvhD2vFoPKrt5a/CMIxhvJPhbwMBCkA0VeVstbvddXb3UIGYdCLRUA SmM/q7wtBewr4UJR8wAt3PU0BNvXr6cC0T4/fTn6oQ1XEqsdS0bgrrl13tAzw4q9uDtR a3Rw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-type :content-transfer-encoding; bh=uJN0xpXpWUZ1Ey7Vk6xenPkRJ+Cp0xBhSJXMca3wj7g=; b=JHZ0ar5Fl0bWf81jyoW9v2fGuPiYfQCLkBP76DqlnP+jkgzE25CK2LCBKUI1jAskBg TCyABN273sQlAqjnr9fsjZUIilSlscEXEv8gbWWBLQ+b/cf8/VmKhLnRFdusu4YfP2BC H6k6OJsuMWxIXmc3RC2eL/h5kJYqaIKNsX41bdMFm72swr/gCLg/lZlu/p+UEGao/B/I lBbllvXo1UcAIwENCedweUUR7uUuhlJDzrc8hJxCguSR6T1HiXsWL8Xzs8d2nGfI8J2m Bxe64iX3olGIAvojW9cYxfaygW4D+1Hstu0RsW2UrSI+mFTo1HKQFuXH5l1sN7jYt+9I k1SQ==
X-Gm-Message-State: AG10YOSu/9HJjXZN/wOxpSm5Ljah8wmsI9FdDhBm0JWqLhc88XCNnRO80wd0PartBVaNFQ==
X-Received: by 10.112.198.162 with SMTP id jd2mr1313896lbc.53.1455569147138; Mon, 15 Feb 2016 12:45:47 -0800 (PST)
Received: from [10.0.0.100] (109107011157.gdansk.vectranet.pl. [109.107.11.157]) by smtp.googlemail.com with ESMTPSA id y63sm3882694lfd.10.2016.02.15.12.45.45 (version=TLSv1/SSLv3 cipher=OTHER); Mon, 15 Feb 2016 12:45:46 -0800 (PST)
To: Robert Sparks <rjsparks@nostrum.com>, General Area Review Team <gen-art@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "dhcwg@ietf.org" <dhcwg@ietf.org>, draft-ietf-dhc-dhcpv6-privacy.all@ietf.org
References: <56B0DBA3.2050406@nostrum.com>
From: Tomek Mrugalski <tomasz.mrugalski@gmail.com>
X-Enigmail-Draft-Status: N1110
Message-ID: <56C238F8.4040400@gmail.com>
Date: Mon, 15 Feb 2016 21:45:44 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1
MIME-Version: 1.0
In-Reply-To: <56B0DBA3.2050406@nostrum.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/gen-art/x9uVjA2T9QzPHDlifhHhc1S6Hx0>
Subject: Re: [Gen-art] Gen-ART LC review: draft-ietf-dhc-dhcpv6-privacy-03
X-BeenThere: gen-art@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "GEN-ART: General Area Review Team" <gen-art.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/gen-art>, <mailto:gen-art-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/gen-art/>
List-Post: <mailto:gen-art@ietf.org>
List-Help: <mailto:gen-art-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/gen-art>, <mailto:gen-art-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Feb 2016 20:45:51 -0000

On 02.02.2016 17:38, Robert Sparks wrote:
> Document: draft-ietf-dhc-dhcpv6-privacy-03 Reviewer: Robert Sparks 
> Review Date: 2Feb2015 IETF LC End Date:4Feb2015 IESG Telechat date:
> Not yet scheduled
> 
> Summary: Ready with nits that should be addressed before publication
Thanks for your thorough review. I did my best to address your comments.
The soon to be published -04 is available here:

https://github.com/dhcwg/privacy/blob/master/draft-ietf-dhc-dhcpv6-privacy-04.txt

You can see the diff here:
https://github.com/dhcwg/privacy/commit/11d08e981fc503d11f31938af05316b7e881bfd6
(scroll down to draft-ietf-dhc-dhcpv6-privacy.xml to see the actual
changes).

> The reference to ietf-6man-ivp6-address-generation-privacy should be 
> normative, and when this document is pointing to it because it is 
> discussing a field carrying a generated address, it should be more 
> explicit about why it's making the reference.
It is normative now. Every reference to this I-D mentions specific
section (See Section 3.2 of ...) and explains that the reference was
made to point to an extended description of each type of attacks. If
this is not sufficient, can you point to specific section or text that
requires further improvement?

> In section 4.3 the paragraph on Hash allocation should note that even
> a well implemented hash does not mitigate the threat of correlation
> over time.
Added. Also added an explanation about the performance. See my response
below why I think it's appropriate.

> In section 4.3, the paragraph on Random allocation comments on the
> poor performance of a specific simplistic implementation of random
> selection. More efficient algorithms exist. But the discussion is
> mostly irrelevant to the document. Please simplify this paragraph to
> focus on the benefits of random allocation.
I somewhat disagree. First, there are more efficient algorithms known,
but they are not always used. This document is a analysis, so we tried
to provide an analysis of what's actually happening in actual
implementations. In an ideal world where privacy is the top priority
every implementation would use truly random allocation using hardware
entropy generators. Sadly, the reality of DHCP servers market is that
performance matters a lot. Lowered performance is a price for better
privacy. This fact directly affects DHCP server implementors, which are
the target audience for this document. These are my arguments why the
discussion about performance penalty is there and should stay in my opinion.

But I think I see your point. The performance aspect was raised only in
random allocation, so it may be mis-interpreted as a way to discredit
random strategy. It is not. I added similar discussion to hash
allocation and added a bit of clarification text. Hopefully it is not
biased in any direction.

BTW This strategy is called random, but the text now explains that it's
really pseudo-random. I can envision a way to hook a hardware random
number generator to a device running DHCP server, but I never heard
about such a solution. Therefore I think pseudo-random is the right word
to use here.

Please let me know if the updated text is satisfactory for you. If not,
I'd love to know which part requires further work.

> Should section 5.3 also call out mapping IP addresses into
> geolocation?
Added a paragraph. I'm not a geolocation expert by any stretch of
imagination, so please correct me if I got it wrong. In general, any
global address assigned by DHCP (or SLAAC for that matter) is
susceptible to the geolocation procedures and the text now clearly
mentions that.

> Why doesn't section 5.5 also talk about things like MAC addresses?
Because there are no MAC addresses in DHCPv6, at least not in the
general case. This is a common surprise, so I added a clarification text
that tries explains it, without going into too much details (it's a
broad topic). Please let me know if the text is sufficient or you want
me work on it further.

> Section 5.6 could probably borrow words from RFC7258 - it should at 
> least reference it (currently there is only a reference from the 
> introduction.)
Good point. It now borrows heavily and references RFC7258.

Also updated one out of date reference.

Thanks a lot for your review and comments.

Tomek