Re: [dhcwg] WGLC on draft-ietf-dhc-dhcp-privacy-01 - Respond by Sept. 22, 2015

Marcin Siodelski <> Tue, 22 September 2015 18:00 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 8C44F1A9163 for <>; Tue, 22 Sep 2015 11:00:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KQVtQLmR5BDz for <>; Tue, 22 Sep 2015 11:00:04 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4010:c03::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A757D1A9054 for <>; Tue, 22 Sep 2015 11:00:03 -0700 (PDT)
Received: by lanb10 with SMTP id b10so21853890lan.3 for <>; Tue, 22 Sep 2015 11:00:01 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-type:content-transfer-encoding; bh=sk6mOc0HeJxX4wcF1pqSIvxokQxHhr7FewBM7/8C+qQ=; b=ySESMa0MUkIqevGPTOgECksznqrF9P2GfuVCU8z145cT/OlTsEojWZExb4o0aA6ruG hsrhfW4x2SxO07aEZ/3Q1KAjN98Vlv6StEmYtLfIVwghCAvY42D2xlBnhNi49sOWk6VN 6eoRYI4RohLP94PSXHk8mKbalrMPw6CXsjk4fzfhadctIkXLgqduSr2MGTngaWMDTDEf X+E2sAHLzN6TdoTSi+g7Ijdqt84OZlvi51I0P/MTrdFGd1h/bBPPyU16U8nBKYAds0ms 95+eeEzIfMShPWJzB+3d7OhNMn8E9fqORA0V1KM7TqxucxPrsp562dKZ+45135xD9yGX qTbA==
X-Received: by with SMTP id g69mr3047496lfi.12.1442944801830; Tue, 22 Sep 2015 11:00:01 -0700 (PDT)
Received: from MacBook-Pro-Marcin.local ( []) by with ESMTPSA id cb9sm336532lad.48.2015. (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 22 Sep 2015 11:00:00 -0700 (PDT)
To: Tomek Mrugalski <>,
References: <> <>
From: Marcin Siodelski <>
X-Enigmail-Draft-Status: N1110
Message-ID: <>
Date: Tue, 22 Sep 2015 20:00:00 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Archived-At: <>
Subject: Re: [dhcwg] WGLC on draft-ietf-dhc-dhcp-privacy-01 - Respond by Sept. 22, 2015
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 22 Sep 2015 18:00:12 -0000

I have read this document and I support advancing it in general, but
this document (as well as the companion v6 document) requires another
revision which corrects some of the issues (mostly nits).

I have similar comments about typos and some little errors in the text,
which I already mentioned for the companion DHCPv6 document. It would be
best to make the proof reading of the whole document and correcting
these errors before submitting it to IESG, to avoid the concerns about
lack of diligence.

Some other comments follow...

3.2. Address Fields & Options

"The 'yiaddr' field [RFC2131] in DHCP message is used to allocate
   address from the server to the client."

The 'yiaddr' field [RFC2131] in DHCP message is used to convey allocated
address  from the server to the client.

3.3. Client FQDN Option

" ... with the associated AAAA and PTR RRs." Did you mean A rather than


"   After the relevant DHCP exchanges have taken place, the location
   information is stored on the end device rather than somewhere else,
   where retrieving it might be difficult in practice."

Similar comments as for the DHCPv6 document:
- what is end device?
- what is somewhere else?
- retrieving? you mean by an attacker who want to obtain sensitive
information about the client?


"   The Client System Architecture Type Option [RFC4578] is used by DHCP
   client to send a list of supported architecture types to the DHCP
   server.  It is used to provide configuration information for a node
   that must be booted using the network rather than from local storage.

This option is not used to provide configuration information but it is
rather sent by the client to ask for the specific configuration conveyed
in different options. no?


"   This section describes available DHCP mechanisms that one can use to
   protect or enhance one's privacy."

I don't think it is really true for this section. It rather describes
the mechanism that makes the client vulnerable to some sort of attacks,
rather than to protect.


On 16.09.2015 20:45, Tomek Mrugalski wrote:
> With my co-chair hat off: I think the problem of DHCP privacy is
> important and DHC should publish problem analysis document such as this
> one. Therefore I support this document moving forward.
> Disclaimer: I'm a co-author of this draft.
> With my co-chair back on, I'd like to remind people that while this
> document has been presented during DHC meetings several times and always
> had favourable reception, the continuous support for it is not implied.
> It is really helpful if you could clearly say that you support this
> document (or state your objections if you don't). Doing a simple +1 is
> useful, doing a thorough review is better.
> Tomek
> On 02.09.2015 23:44, Bernie Volz (volz) wrote:
>> This message starts the DHC Working Group Last Call to advance
>> draft-ietf-dhc-dhcp-privacy-01, Privacy considerations for DHCPv4  -- 
>> This
>> document’s intended status is Informational. At present, there is no IPR
>> file against this document.
>> This is a part of the WGLC of 3 documents
>> (draft-ietf-dhc-dhcp-privacy-01,  draft-ietf-dhc-dhcpv6-privacy-01, and
>> draft-ietf-dhc-anonymity-profile-03).
>> Please send your comments by September 22th, 2015. If you do not feel
>> this  document should advance, please state your reasons why.
>> Bernie Volz is the assigned shepherd.
>> - Tomek & Bernie
> _______________________________________________
> dhcwg mailing list