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

From: "Ben Campbell" <[email-masked]>
Date: Tue, 16 Feb 2016 18:10:08 -0800

Ben Campbell has entered the following ballot position for
draft-ietf-dhc-anonymity-profile-07: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dhc-anonymity-profile/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

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?

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Feb 2016 20:58:30 +0000

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

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.

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

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

Yes.

> -3.3, 2nd paragraph: "They MUST use the option when mandated by the
> DHCP protocol..."

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.

> numbers, or mention "The remaining subsections"?

"The remaining subsections" looks good.

> Are we really talking about clients "willing" to protect privacy, or clients
> "wishing" or "intending" to protect privacy?

"intending" is fine.

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

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

> overstated. I suspect there are other ways clients can leak private

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

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

> I suggest removing the clause. It weakens the following normative

OK.

> - 4.5, first paragraph: "indemtified"

Yes.

Thanks for the feedback!

-- Christian Huitema