[dhcwg] Comments on draft-ietf-dhc-anonymity-profile-02.txt

["Bernie Volz (volz)" <[e-mail]>]

Hi:

In preparation for a (hopefully soon) WGLC, I did a more thorough review of this document. Comments are "inline" below (BV>). While many of the findings are minor nits, there are a few more significant issues as well. Though nothing that shouldn't be difficult to correct. And, feel free to push back if you don't agree with some comments.

- Bernie

Abstract

   Some DHCP options carry unique identifiers.  These identifiers can
   enable device tracking even if the device administrator takes care of
   randomizing other potential identifications like link-layer addresses
   or IPv6 addresses.  The anonymity profile is designed for clients
BV> Should it just be IP addresses? DHCPv4 can lease addresses too in the INIT-REBOOT phase.
   that wish to remain anonymous to the visited network.  The profile
   provides guidelines on the composition of DHCP or DHCPv6 requests,
   designed to minimize disclosure of identifying information.  This
   draft updates RFC4361.
BV> We need to review whether this updates RFC4361 is correct. There is not explicit "change this to that" text so it isn't really an "updates" in the strict sense. It is just to change its use for privacy, but then this would also update RFC 2131 and 3315? So is it really appropriate?

2.  Application domain
...
   "privacy" addresses.  Privacy advocates have some reason to be
   concerned.
BV> Some reasons?

2.2.  MAC Address Randomization and DHCP

   From a privacy point of view, it is clear that MAC Addresses, IP
BV> MAC address? Please check other usages as there were a bunch of these cases.

2.3.  Radio fingerprinting

   MAC address randomization solves the trivial monitoring problem in
   which someone just uses a Wi-Fi scanner and records the MAC addresses
   seen on the air.  DHCP anonymity solves the more elaborated scenario
   in which someone monitor MAC addresses and identities used in DHCP at
BV> monitors
   the access point or DHCP server.  But this are not the only ways to
BV> this are -> these are or this is ... way?
   track a mobile device.

2.5.  No anonymity profile identification
...
   example a new type of DUID of temporary DUID that would be changing
BV> "DUID of " -> "DUID for a"? Just seems odd to have of .. of?
   over time.

...
   anonymity is a bit like walking around with a Guy Fawkes mask.  When
BV> Show this have some kind of reference for the international audience or do you think it is globally clear?

BV> 2.6 and perhaps elsewhere, replace [I-D.ietf-dhc-dynamic-shared-v4allocation] with RFC 7618.

2.7.  What about privacy for DHCP servers

   The server part will be covered by the general mitigation work going
   on in DHCP working group, following the analyses presented in
   [I-D.ietf-dhc-dhcp-privacy] and [I-D.ietf-dhc-dhcpv6-privacy].
BV> Isn't this part of this work? Perhaps we say it is a topic for further work/study?

3.  Anonymity profile for DHCPv4

...

   RELEASE:  The anonymized RELEASE messages SHOULD contain the Message
      Type, Client Identifier and Server Identifier options.

   INFORM:  The anonymized INFORM messages MUST contain the Message
      Type, Client Id, and Parameter Request List options.  It SHOULD
      NOT contain any other option.
BV> Should this be "Client Identifier" to match earlier usage? 

BV> Also there is a general question (may impact 3.4) of why these clients even include a client-identifier option? It isn't required so perhaps one option is for them not to include it. That way, no value must be derived?

3.1.  Client IP address field

   Four bytes in the header of the DHCP messages carry the "Client IP
   address" (ciaddr) as defined in [RFC2131].  In DHCP, this field is
   used by the clients to indicate the address that they used
   previously, so that as much as possible the server can allocate them
   the same address.

BV> I'm not sure what cases this is to cover - perhaps just normal DHCPREQUEST for renew, since for INIT-REBOOT, RFC 2131 has:

For RFC 2131:

   o DHCPREQUEST generated during INIT-REBOOT state:

      'server identifier' MUST NOT be filled in, 'requested IP address'
      option MUST be filled in with client's notion of its previously
      assigned address. 'ciaddr' MUST be zero. The client is seeking to
      verify a previously allocated, cached configuration. Server SHOULD
      send a DHCPNAK message to the client if the 'requested IP address'
      is incorrect, or is on the wrong network.
BV> END

   they know that the network attachment has changed, and in particular
   of the link layer address is reset by the device's administrator.
BV> of should be if

3.2.  Requested IP address option

   The Requested IP address option (code 50) allows the client to
   request that a particular IP address be assigned.  The option is
BV> For consistency, perhaps use "The Requested IP address option is defined in [RFC2132] with code 50 and ..."

   When using the anonymity profile, clients SHOULD NOT use the
   Requested IP address option in DHCPDISCOVER Messages.  They MUST use
   the option when mandated by the DHCP protocol, for example in
   DHCPREQUEST Messages.

BV> lowercase Message(s)? Check elsewhere.

3.4.  Client Identifier Option

   The client identifier option is defined in [RFC2132] with option code
   61.  It is discussed in details in [RFC4361].  The purpose of the
BV> details -> detail?

BV> Also, see above as to why even send this at all?
BV> Note that if a client is dual stack and doing DHCPv4 and DHCPv6, it may be best that the 4361 requirement to send is used as then it would be possible to correlate the client's V4 and V6 address. But that can also be a privacy risk? Should this be discussed?

   In contradiction to [RFC4361], When using the anonymity profile, DHCP
BV> When -> when?

BV> New section between 3.4 and 3.5 to include the PRL similar to ORO text in 3.5? Kind of odd that the Parameter Request List isn't mentioned at all for DHCPv4 where there exists a fairly extensive fingerprinting database (mostly based on the PRL).

4.  Anonymity profile for DHCPv6
...

   The choice between the stateful and stateless scenario depends of
BV> depends on?
   flag and prefix options published by the "Router Advertisement"
   messages of local routers, as specified in [RFC4861].  When these
   options enable stateless address configuration hosts using the
   anonymity profile SHOULD choose it over stateful address
   configuration, because stateless configuration requires fewer
   information disclosure than stateful configuration.
BV> disclosure -> disclosures

   When using the anonymity profile, DHCPv6 clients carefully select
   DHCPv6 options used in the various messages that they sent.  The list
BV> sent -> send

4.1.  Do not send Confirm messages, unless really sure where

   The [RFC3315] requires clients to send a Confirm message when they
BV> Drop The?

4.2.  Client Identifier DHCPv6 Option

   The client identifier option is defined in [RFC3315] with option code
   1.  The purpose of the client identifier option is to identify the
   client to the server.  The content of the option is a DHCP User ID
BV> DHCP Unique Identifier (not DHCP User ID).

   tracking and profiling.  Three DUID formats are specified: Link-layer
   address plus time, Vendor-assigned unique ID based on Enterprise
   Number, Link-layer address.
BV> There is a 4th type, DUID-UUID defined in RFC 6355. Probably not a good idea to use this for privacy?

   cases the link-layer address is based on MAC.  The first three octets
   are composed of the OUI (Organizationally Unique Identifier) that is
   expected to have a value assigned to a real organization.  See
   [IEEE-OUI] for currently assigned values.  Using a value that is
   unassigned may disclose the fact that a DUID is randomized.  Using a
   value that belongs to a third party may have legal implications.
BV> I don't understand what the value of these last sentences is? It mentions the OUI but so what should someone do? What about the other octets??

4.4.1.  Obtain temporary addresses

   [RFC3315] defines a special container (IA_TA) for requesting
   temporary addresses.  This is a good mechanism in principle, but
   there are a number of issues associated with it.  First of all, this
   is not widely used feature.  Thus clients cannot count on it to be
BV> is not a widely used feature?
   always available.  Secondly, [RFC3315] does not specify any renewal
   mechanisms for temporary addresses.  Therefore the support for
BV> Yes it does. See RFC 3315, page 76 2nd paragraph?
   renewing temporary addresses in server implementations usually varies
   between poor and non-existent.  Finally, a client reveals its desire
   for privacy just by requesting temporary addresses, and potentially
   risks countermeasures as described in Section 2.5.

   needs to release the first one (using an old IAID) and then retry
   asking for a new address.
BV> "using the old IAID" would be better since client has to use the IAID under which address was obtained.

4.8.  Client FQDN Option

   The Client FQDN option is defined in [RFC4704] with option code 29.
   The option allows the DHCP clients to advertize to the DHCP their
BV> fix advertise spelling? And "to the DHCP server their".

6.  Security Considerations
BV> This is a bit light, but don't have any real recommendations - might reference RFC 2131 and 3315, but that might not help that much? I guess we'll see what the IESG or other reviewers say?

9.  Changes from previous versions

   Changes from draft-00 to draft-01:
BV> Might be worth a note that the RFC editor should remove this material?


Finally, be sure to run id-nits!!!

It does report (some of these are likely because of publications updated since this draft was posted):

  Checking references for intended status: Proposed Standard
  ----------------------------------------------------------------------------

     (See RFCs 3967 and 4897 for information about using normative references
     to lower-maturity documents in RFCs)

  == Outdated reference: A later version (-07) exists of
     draft-ietf-6man-default-iids-05

  == Outdated reference: A later version (-07) exists of
     draft-ietf-6man-ipv6-address-generation-privacy-03

  == Outdated reference: A later version (-01) exists of
     draft-ietf-dhc-dhcpv6-privacy-00

  == Outdated reference: draft-ietf-dhc-dynamic-shared-v4allocation has been
     published as RFC 7618

- Bernie