Anonymity Profiles for DHCP Clients
draft-ietf-dhc-anonymity-profile-08

Great work, thanks.

= General =

This document seems to use the term "link-layer address randomization" to describe the situation where a link-layer address is randomly generated AND changes over time. While this seems the likely way that such addresses may be standardized in the future, it's not guaranteed. An address could be randomly generated (or otherwise semantically opaque, e.g. not containing an OUI) but permanent for the life of the device/interface, in which case the privacy benefits of what is specified in this draft are not the same. Therefore I think it's worth explicitly stating the interpretation of "random address" that is being used here.

= Section 1 =

s/Reports surfaced recently/There have been reports/

= Section 2 =

Would be good to update the references to work going on in IEEE 802.1. Also there were experiments at multiple IEEE and IETF meetings. 

= Section 3 =

Section 3.1 says:

"The client willing to protect its privacy SHOULD limit the subset of
   options sent in messages to the subset listed in the following
   sections."

Then all the subsections discuss specific options and considerations for using them, except 3.9, which basically says "don't use these." I would assume there are a bunch of other options that clients definitely shouldn't use if they want to maintain anonymity (I was thinking of 123 and 144, geolocation). So why are only the PXE options mentioned here, when the text in 3.1 seemed to be saying that clients should avoid all other options not mentioned?

Thanks for doing this. I have some comments, most of which can be safely ignored:

*** Substantive ***
- 2.6, 2nd paragraph:
It seems like the "if servers do not object" part goes against the spirit of section 2.5.

- 3 (top level)

-- There's a lot of normative language about things people MUST or MAY put into DHCP messages (as opposed to the SHOULD NOTs). Are those new requirements created by this profile, or statements of fact about DHCP in general? If the latter, please consider dropping the 2119 keywords.

-- "It SHOULD NOT contain any other option"
This language repeats several times. But there’s a fair amount of text later in the subsections that talks about specific “other options” that SHOULD NOT be included. That seems redundant. I wonder if there's an opportunity to simplify things?

-- 2nd to last paragraph:
It seems odd to say things SHOULD follow the dhcp standard; that's kind of implied by being dhcp.

- 3 and subsections:
There are a lot of SHOULDs that I am surprised are not MUSTs. I understand that the entire profile is optional, but it seems like some of the guidance could be stronger for clients that use the profile in the first place.

- 3.1, last paragraph:
Please describe the consequences of not following that SHOULD. For example, doesn’t the MAY alternative _add_ a fingerprinting opportunity?
- 3.2, 2nd to last paragraph: "DHCP clients should ensure"
Should that be SHOULD?
-3.3, 2nd paragraph: "They MUST use the option when mandated by the DHCP protocol..."
That seems more like a statement of fact.

-3.7, third paragraph:
What’s the point of allowing the sending of an obfuscated host name, rather than just saying MUST NOT send the host name in the first place?

- 4.3, 3rd paragraph:
Isn't the randomization of link-layer addresses a fundamental premise of this draft?

*** Editorial ***

- 3, 2nd to last paragraph:
Can the "following sections" be more specific? That is, list the section numbers, or mention "The remaining subsections"?

- 3.1, 2nd to last paragraph:
Are we really talking about clients "willing" to protect privacy, or clients "wishing" or "intending" to protect privacy?

- 3.4:
The document already spent several pages motivating the randomization of link-layer addresses. It seems unnecessary to do it again here.

-3.5, 2nd to last paragraph:
“based solely” seems ambiguous. Do I understand correctly that this means the client MUST NOT use client identifiers that persist across changes in the link layer address?
The assertion that this will ensure that no privacy leaks occur seems overstated. I suspect there are other ways clients can leak private information.

- 3.6:
The guidance on ordering seems redundant with 3.1.

- 3.9, 2nd paragraph, last sentence: "If only for privacy reasons..."
I suggest removing the clause. It weakens the following normative requirement. 

- 4.5, first paragraph: "indemtified"
identified?

Thanks. Happy to see this work, along with the trade-off analysis.

Thank you for producing this document. It's important. I do have a couple of observations for you to consider.

In this text:

   We can also
   assume that privacy conscious users will attempt to evade this
   monitoring, for example by ensuring that low level identifiers such
   as link-layer addresses are "randomized," so that the devices do not
   broadcast a unique identifier in every location that they visit.
   
it would be clearer to me if it said "broadcast the same unique identifier".

I really like 

   Declaring a preference for
   anonymity is a bit like walking around with a Guy Fawkes mask.
   
but I do wonder if that's accessible for a global audience. Is there a reference, or a short explanation that would work?

Thank you for doing this work. I think it's important and an
excellent example. 

- general: I have a question for which I think it'd be good if
the answer were visible to others doing similar work later. That
could be recorded in email that can be referenced (via an
archive URL) or it could be in this document. Perhaps the latter
is better, not sure.  Anyway, the question is: what was the
methodology used to identify the various DHCP related anonymity
issues that need to be tackled, and to consider/test proposed
mitigations? I think it may be worth including some text on
methodology in this document (maybe a new appendix or as a
section 2.8?) so that we can use this as a self-contained
example when other folks are doing similar work.  (Sorry for
trying to add work.) If a part of that answer is e.g. "I bought
Ralph a G&T" that is IMO also worth including in some anonymised
form:-)

- The IPR declaration makes me a bit sad, but I think the WG
did process it according to our processes.

- abstract: Is "anonymous to the visited network" the right
goal? Perhaps also "not be identified as the same entity as
previously connected to this or another network" is more like
it, but too wordy;-) If you can figure a way to include the
"another network" aspect in the abstract that'd be good I think,
as that might help motivate network admins to want this profile,
as they're not only protecting their users from themselves, but
from other network admins as well.

- section 2: In the introductory text, you could update this to
refer to IEEE's ongoing work here, which I think is now more
official than it was perhaps when this text was written.

- 2.5: The Guy Fawkes reference might not be meaningful in a
few years. I'd suggest deleting that sentence.

- 3.5: So this says to do the opposite of 4361, which is
correct.  I wonder does that mean this UPDATEs 4361? (But don't
care about the answer;-) Same issue may arise wrt 3315 I guess.
(And I still don't care about the answer:-)

- 3.7: typo, "SOULD"

- 4.3: "from the previous year" - that's neat! Don't think I've
seen that before.

- 4.5: typo, "indemtified"

- 4.5.2: This still seems a bit too negative to me. Can't PD
assist privacy in some cases even if further study is needed.
E.g. if a home router is given a prefix via PD and that changes
now and then.

- DHCPv6: is there really nothing to say about link local
addresses? (I'm not sure how those are used in DHCPv6, if they
are, but they do often contain MACs.)

- The secdir review of the dhcp-privacy draft [1] suggested some
additional text for the security considerations text there that
might be better here.

   [1] https://www.ietf.org/mail-archive/web/secdir/current/msg06338.html

(PS: This review was done on -06 with a quick look at the diff
vs. -07. I think it all still applies though.)