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

From: "Alissa Cooper" <[email-masked]>
Date: Wed, 17 Feb 2016 13:01:57 -0800

Alissa Cooper 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:
----------------------------------------------------------------------

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?

---

From: Christian Huitema <[email-masked]>
Date: Fri, 19 Feb 2016 21:50:25 +0000

On Wednesday, February 17, 2016 1:02 PM, Alissa Cooper wrote:
> ...
> 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.

Would you add something to section 2.1, MAC address Randomization hypotheses?

> s/Reports surfaced recently/There have been reports/

OK.

> Also there were experiments at multiple IEEE and IETF meetings.

Yes, will add a reference to the IEEE work.

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

The real requirement is "do not advertise unique identifiers or previously assigned parameters." We scrutinized the options that did that, and PXE is one of them. And we limit the list of options and values that can be inserted in client messages. But we do not limit the number of options that can be requested by the clients.

The draft does not preclude adding request codes in the Parameter Request List. RFC 6225 says "DHCPv4 clients request the DHCPv4 server to send GeoConf Option 123, GeoLoc Option 144, or both via inclusion of the Parameter Request List option." That's fine. The client is not disclosing anything, except its willingness to read the information provided by the server. 

The main issue is that the geoloc option values can be sent back by the server in clear text, and thus monitored. Monitoring just the local link will reveal the location of the local link, which is not that big a deal. Monitoring happens between a proxy and a centralized server is of course more "interesting." But the anonymity profile provides a mitigation against both: sure, the monitor can read the geoloc information; but since the device is anonymous, the monitor does not know who travelled at that location.

-- Christian Huitema