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

From: "Stephen Farrell" <[email-masked]>
Date: Mon, 15 Feb 2016 10:44:46 -0800

Stephen Farrell 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:
----------------------------------------------------------------------

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

---

From: Christian Huitema <[email-masked]>
Date: Mon, 15 Feb 2016 21:43:10 +0000

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

:-)

> Ralph a G&T" that is IMO also worth including in some anonymised

There are several parts to this. One is "how do you get a working group to take on the work?" That includes of course a mix of technical arguments and personal relations. This is not different from any IETF work, with individual draft submissions progressing to WG adoption. 

The second part is "how do you identify privacy issues in an existing protocol." If I wrote a process document, I would describe something similar to security analyses: describe the system architecture, describe the "privacy assets," analyze the attacks, provide mitigations. But there are also gut feelings and a long history. 

We have known since the early 90's that carrying unique identifiers in MAC addresses of mobile devices could have privacy implications. We have refrained from doing anything about it for many years base on the "multiple leaks" theory: why randomize the MAC addresses if DHCP is going to divulge the machine's DNS name? And why protect DHCP if the DNS traffic is also going to reveal the user's identity? And what about email in clear text? Or the user tracking through web cookies?

I think we saw a big change of attitude in 2013, that drives us to plug as many leaks as we can.

> official than it was perhaps when this text was written.

We can certainly change the reference to point to the IEEE effort.

> few years. I'd suggest deleting that sentence.

We went back and forth on this one, looking at the "cultural reference" argument. The decision to keep it was very conscious.

> (And I still don't care about the answer:-)

That too was actively discussed. The initial versions of the draft mentioned "update 4361," but that reference was removed after WG feedback. The point is that we do not update any specific portion of 4361. Instead, we provide guidance on how to interpret or use 4361.

> - 3.7: typo, "SOULD"

Dang. Will fix in next edit.

> - 4.5: typo, "indemtified"

Will fix.

> E.g. if a home router is given a prefix via PD and that changes

There is not a lot of deployment experience with "client PD," or mobile devices roaming to a hot spot and asking for delegation of a prefix. What you describe here probably belongs to a different effort: rotating addresses and prefixes in home networks, with the cooperation of the ISP, in order to prevent tracking of traffic by addresses. Looks like something for INTAREA, not DHCP. 

> are, but they do often contain MACs.)

Local addresses are assigned by the host before starting DHCPv6. This is an IPv6 issue, and the draft points to the ongoing work in 6MAN: draft-ietf-6man-ipv6-address-generation-privacy.

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

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Mon, 15 Feb 2016 22:04:02 +0000

Hiya,

(Trimming to the interesting bit.)

On 15/02/16 21:43, Christian Huitema wrote:
>> - 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:-)
> 
> There are several parts to this. One is "how do you get a working
> group to take on the work?" That includes of course a mix of
> technical arguments and personal relations. This is not different
> from any IETF work, with individual draft submissions progressing to
> WG adoption.

Agreed. I don't think there's anything to include here about this.

> 
> The second part is "how do you identify privacy issues in an existing
> protocol." If I wrote a process document, I would describe something
> similar to security analyses: describe the system architecture,
> describe the "privacy assets," analyze the attacks, provide
> mitigations. But there are also gut feelings and a long history.
> 
> We have known since the early 90's that carrying unique identifiers
> in MAC addresses of mobile devices could have privacy implications.
> We have refrained from doing anything about it for many years base on
> the "multiple leaks" theory: why randomize the MAC addresses if DHCP
> is going to divulge the machine's DNS name? And why protect DHCP if
> the DNS traffic is also going to reveal the user's identity? And what
> about email in clear text? Or the user tracking through web cookies?
> 

So, from watching this, I think I saw the following "method" being
applied (or something similar) and I continue to wonder if describing
something like this might help the next set of folks who take on
doing similarly good work.

Trying to cast this as text that could be the starting point for
inclusion as a new section 2.8 or appendix, maybe that'd be
something like:

"In outline, the process leading to this specification, was to,
within the usual IETF consensus process [BCP9]:

1. Get some level of agreement that there are privacy issues to
   address with protocol <foo> and assemble people willing to help,
   some who know about <foo> and some who know about privacy.
2. Identify relevant issues by surveying RFCs, implementations and
   deployments.
3. Discuss (in a WG or wherever) how one might mitigate those
   privacy issues, and the effects of mitigations (including
   ways in which mitigations may break things done today).
4. Figure out which mitigations can be deployed without breaking
   things badly and that do usefully improve privacy.
5. Write a profile of <foo> and/or update <foo> to be more
   privacy friendly, documenting #2-#4.

While this sequence can take some time (a year or two), it should
lead to results that are more likely to get widely deployed, compared
to simply developing an implementation of <foo> that includes your
own preferred set of privacy enhancements."

I think the above is reasonably accurate, but I'm really not sure
how much it's utterly obvious or if it'd be useful for a new set
of people working on privacy issues of the next <foo>.

Cheers,
S.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 16 Feb 2016 01:11:45 +0000

On Monday, February 15, 2016 2:04 PM, Stephen Farrell wrote: 
> ...

Looking at "metadata minimization," we have three or four successful experiences so far, and one spectacular failure. We see work progressing well and early deployments for DHCP privacy, IPv6 address privacy, DNS minimization and DNS privacy. We also see the early effort on email metadata minimization stalled after a spectacular flame fest. Rather than just focusing on DHCP, may I suggest that we work on a separate draft comparing what worked and what did not?

-- Christian Huitema

---

From: Stephen Farrell <[email-masked]>
Date: Tue, 16 Feb 2016 01:22:12 +0000

Hiya,

On 16/02/16 01:11, Christian Huitema wrote:
> Looking at "metadata minimization," we have three or four successful
> experiences so far, and one spectacular failure. We see work
> progressing well and early deployments for DHCP privacy, IPv6 address
> privacy, DNS minimization and DNS privacy. We also see the early
> effort on email metadata minimization stalled after a spectacular
> flame fest. Rather than just focusing on DHCP, may I suggest that we
> work on a separate draft comparing what worked and what did not?

That does sound better, yes. But also more work. However, if you're
up for it... maybe let's chat about that separate from this
document, say on the perpass list?

I'd still argue it may be worth capturing what's worked well in this
case though, as I think it'd be fine to have that in this document
too. But, this isn't meant to be anything like blocking, so I'm
fine with whatever you (authors, chairs, responsible AD) prefer.

Cheers,
S.