Re: [dhcwg] Ben Campbell's Yes on draft-ietf-dhc-anonymity-profile-07: (with COMMENT)

[Christian Huitema <[e-mail]>]

On Tuesday, February 16, 2016 6:10 PM, Ben Campbell wrote:

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

I guess we can suppress the "if server do not object" part. Servers could do all kind of things, but this specification is really for clients.

There is an example in section 5 of how servers might object -- by enforcing a white list of MAC addresses. Probably no need to say that again in 2.6.

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

The part specific to the anonymity profile is the restriction, "should not contain more options." The MUST part is largely a repeat of the main spec.

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

We went through several iterations of this text, and it was thoroughly reviewed. I am concerned that changing something now would require going back to the WG.

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

Yes. What is meant is that since this is DHCP, we will of course follow the standard, but we are going to have some deviations and choices, as explained in the remaining subsections. Do you have a better text?

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

The problem is that in many case there is a conflict between perfection and usability, as well as doubts about how far to go to avoid fingerprinting.
 
> - 3.1, last paragraph:
> Please describe the consequences of not following that SHOULD. For
> example, doesn’t the MAY alternative _add_ a fingerprinting opportunity?

We can debate that. What you see there is a compromise between theory and practice. Our Windows 10 implementation actually uses the fix order, because that can be set at compile time. Also, we use the same fixed order whether or not the client is using anonymity profile. So you could say that not randomizing fingerprints the device as "running windows 10", while randomizing would fingerprint as "using the anonymity profile."

> - 3.2, 2nd to last paragraph: "DHCP clients should ensure"
> Should that be SHOULD?

Yes.

> -3.3, 2nd paragraph: "They MUST use the option when mandated by the
> DHCP protocol..."
> That seems more like a statement of fact.

Yes. We were concerned that implementers would scratch their head and wonder how to balance the anonymity statement "this is sometimes dangerous" versus the DHCP specification. Do you suggest to drop the sentence?

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

Well, we say "SHOULD NOT" send the host name. This is what the Windows 10 implementation does, and we have verified that it does not cause problems in practice. But during the draft development we were really concerned that some network functionality might require sending a name value in DHCP. 

I am concerned that changing that now will require WG feedback.

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

This is meant for example for anonymous VPN links. There was specific WG feedback requesting that.

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

"The remaining subsections" looks good.

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

"intending" is fine.

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

There is a key requirement to implementers there: do not pick a static value at boot time, but instead always check whether it has changed. But I suppose we could suppress the middle sentence of the 2nd paragraph. 

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

"based solely" is a deliberate repeat of the text in RFC 4361, explaining that we recommend exactly what RFC 4361 recommends against. 

> The assertion that this will ensure that no privacy leaks occur seems
> overstated. I suspect there are other ways clients can leak private
> information.

The text does not say "no privacy leak," it is more cautious than that. But yes, we could be more specific, say ”will not be nullified by the Client Identifier Option" instead of "will not be nullified by DHCP options."

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

It is actually different. 3.1 describe the arrangement of the various options in the message, 3.6 describes the arrangement of the requested option numbers inside the PRL option.

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

OK.

> - 4.5, first paragraph: "indemtified"
> identified?

Yes.

Thanks for the feedback!

-- Christian Huitema