Privacy Considerations for Protocols Relying on IP Broadcast or Multicast
RFC 8386

Note: This ballot was opened for revision 08 and is now closed.

(Alia Atlas) Yes

(Ben Campbell) Yes

Comment (2018-01-23 for -08)
No email
send info
I'm balloting "Yes", but I do have a few comments:

Substantive Comments:

-2.2: "These IDs, which e.g. identify the installation of a
   certain application might not change across updates of the software
   and are therefore extremely long lived"

That seems to imply that they may be extremely long lived, not that they always are.

-2.2, last paragraph: "When protocols that
   make use of broadcast/multicast need to make use of IDs, frequent
   rotations of these IDs SHOULD be considered to make user tracking
   more difficult."
Can this say something stronger than "... be considered..." Maybe "be required"?

-2.3, first paragraph: It seems worth noting that a host name can be a persistent ID even if it contains no personally identifiable info.

-- Same paragraph: The last sentence gives a nod to device fingerprinting. Would it be reasonable to offer some more general guidance around avoiding such fingerprinting?

-2.3, last paragraph: It seems counterproductive to explain better ways of creating persistent IDs after a whole section was dedicated to telling people to avoid them.

-2.4: This section talks about how broadcast/multicast data might be used for correlation.  Is there any reasonable guidance to give on how to avoid that?

-2.5: It seems the configurability discussion could go a bit further and suggest that platforms avoid broadcast/multicast services for features that the user is not actively using.




Editorial Comments and Nits:

-1, paragraph 6: While I like citations of the form of " 'document title' [ref] " better than just "[ref]" , when that becomes "  RFC 7721 [RFC7721] or RFC 7819  [RFC7819]", it adds no information. Please consider replacing "RFC 7221" and "RFC 7819" with something more descriptive.

-1, paragraph 7: " For one, non-standard
   protocols will likely not receive operational attention and support
   in making them more secure such as e.g.  DHCP snooping does for DHCP
   because they typically are not documented."

I find that hard to parse.

-- same paragraph: "... where a set of
   considerations to follow is useful in the absence of a larger
   community providing feedback. "

I don't understand the intent.

-1.1, first paragraph: "The same is true for directed broadcasts by
   default, but routers MAY provide an option to do this [RFC2644]"
That MAY seems like a statement of fact or an external requirement. Neither should use the upper-case MAY.

-1.1, last paragraph: Please expand LLMNR and mDNS on first mention.
-- same paragraph: The last sentence seems out of place in this paragraph. Perhaps it should go with one of the two previous paragraphs?

-1.2: I don't think the use of RFC 2119 keywords adds much value in this document. The document mainly uses them to talk about thins people should consider in protocol design, rather than requirements on the protocols themselves. I suggest making the boilerplate more descriptive of that use, or even better get rid of it (and the capitalized keywords) entirely.

-2.1, last sentence is hard to parse.

-2.2, 2nd to last paragraph: s/" did never " / " never did "
-- same paragraph: "allowed to track" is grammatically incorrect. It should say "allowed <something> to track" or "allowed the tracking of"

-3, 2nd paragraph: By "not uncommonly", do you mean "commonly"?

(Spencer Dawkins) Yes

Comment (2018-01-24 for -08)
No email
send info
I really like this document. I learned a lot. 

I'm not gonna argue, but could this have been a BCP?

I have a couple of comments.

ISTM that 

   When protocols that
   make use of broadcast/multicast need to make use of IDs, frequent
   rotations of these IDs SHOULD be considered to make user tracking
   more difficult.

should be either

   When protocols that
   make use of broadcast/multicast need to make use of IDs, frequent
   rotations of these IDs MUST be considered to make user tracking
   more difficult.

or

   When protocols that
   make use of broadcast/multicast need to make use of IDs,
   these IDs SHOULD be rotated frequently to make user tracking
   more difficult.

assuming that frequent rotation is the goal, not considering frequent rotation.

I'm not surprised that 

   A feature not uncommonly found on access points e.g. is to filter
   broadcast and multicast traffic.  This will potentially break certain
   applications or some of their functionality but will also protect the
   users from potentially leaking sensitive information.

is the only action listed that network administrators/operators can take to limit problems, but I note that the paragraph above it says there are things, plural, that network administrators/operators can do to limit problems, and this action can be paraphrased as "you can filter broadcast and multicast traffic, but then the applications stop working, so make good choices". If that's the only action you can think of, you may want to make the first paragraph sound a bit less hopeful!

Suresh Krishnan Yes

Mirja K├╝hlewind Yes

(Terry Manderson) Yes

Comment (2018-01-24 for -08)
No email
send info
Thank you for the effort invested into this draft. 

I am balloting YES, but like Spencer I wonder if this might be better placed as a BCP.

(Kathleen Moriarty) Yes

Comment (2018-01-24 for -08)
No email
send info
Thanks for your work on this draft and the security and privacy considerations.  Thanks for addressing the SecDir review comments as well.
https://mailarchive.ietf.org/arch/msg/secdir/BshBcsvqHYLLIBjGzEIaVaGefE8

Adam Roach (was No Objection) Yes

Comment (2018-01-24 for -08)
No email
send info
I had a couple of comments, but Ben caught them too; so my comments resolve to: I support Ben's substantive comments.

Deborah Brungard No Objection

Alissa Cooper No Objection

Comment (2018-01-24 for -08)
No email
send info
Section 3 strikes me as a bit odd. Are you implicitly recommending that access points block broadcast/multicast traffic? That does not seem like it would yield a good user experience and also seems like a rather blunt instrument to address the rest of the problems discussed in the document.

Warren Kumari (was Discuss) No Objection

Comment (2018-01-25 for -08)
No email
send info
I found this sentence very confusing:
" For one, non-standard  protocols will likely not receive operational attention and support in making them more secure such as e.g.  DHCP snooping does for DHCP because they typically are not documented. "   -- I know what it is trying to say, but I don't think it accomplishes what it intends to.


[ This was originally a DISCUSS, emails with authors have addressed my concerns. Old text below for posterity]: 
"Sorry for the late DISCUSS. I'm likely to clear after discussions on the call tomorrow.

I'm somewhat surprised at how much this document glosses over the (sometimes extensive) broadcast/multicast twiddling that Access Points and similar do (a fair bit of discussion of which can be found in draft-perkins-intarea-multicast-ieee802 (which I think will be expiring) or draft-mcbride-mboned-wifi-mcast-problem-statement). 
Simply saying: "A feature not uncommonly found on access points e.g. is to filter broadcast and multicast traffic.  This will potentially break certain applications or some of their functionality but will also protect the users from potentially leaking sensitive information." seems to be shrugging off all of the privacy benefits (or possibly harms) that this might create.
"

Alvaro Retana No Objection