[Int-area] IoT-dir early review of draft-ietf-intarea-broadcast-consider

["Nancy Cam-Winget (ncamwing)" <[e-mail]>]

Reviewer: Nancy Cam-Winget
Review result: On the right track

General Comments
There are actual distinctions that need to be made from a general privacy/security
and considerations of using broadcast vs. multicast.  Whereas multicast has
the means by which multicast groups can be managed and thus authentication
and authorization of group membership to a multicast group can be handled,
broadcast does not.  As such, the privacy considerations, while sharing a lot
of commonality between multicast vs. broadcast, hold differences
that need to be called out.

Technical comments:
Introduction:
  The 2 respects called out need to be better clarified:
   For (a):  messages can be protected especially  in a multicast group and keys
            can be managed with membership changes, whereas broadcast is more
           difficult to manage.
   For (b): why is encryption more difficult??  Broadcast/multicast messages today
           are being encrypted, but are subject to full viewership by the key holders
           (e.g. members of the broadcast or multicast domain for the duration of that key)

   The last paragraph is of concern as its intent is not clear. I believe it is trying to state
that the draft is needed as RFC6973 focuses on the general privacy but more care is
needed for broadcast and multicast. If that’s the case, suggest to reduce paragraph
to a sentence or 2 to just highlight that point.

Section 2.1
“Frequent bcast/mcast traffic caused by an application…”
I think you mean the continuous use and the patterns it draws can define
a behavioral pattern….I don’t believe the literal “frequent” lends itself to
improving accuracy, but rather the temporal length of time in observing
such a pattern can improve on the fidelity of the behavioral pattern observed.

In general, making the periodicity of the message use unpredictable is what
can help.  Otherwise, a better rationale or guidance on what “conservative” in
“the frequency SHOULD be chosen conservatively” is needed.

Section 2.2
“true in case the IP and/or MAC address changes”
I think you mean DOES NOT change.  Also, these track devices not users.

I would actually disagree that “frequent rotations of IDs” (in general) make
user tracking more difficult.  This section needs to improve the qualifications
and conditions for when and how it can make tracking more difficult.
While I do not entirely agree with rotation as a solution, I can see SOME
instances in which it can slow down the tracking but not completely obfuscate
behavior that can be used to deduce identity (of a device, or user).

I am also puzzled as to how this is unique to broadcast/multicast messages?

Section 2.4
Need to capitalize the ‘should’ in the last paragraph as the intent is to provide
that as a recommended consideration.

Section 2.5
What is a “safe” environment?  The first paragraph needs to be clear on
intent and definition of what is “safe”.

This section will need to elaborate on the applications developed and where
they sit in the networking layer…..application layer apps may want to use
established ports and addresses that may need to be configured at a lower
layer of the network stack.  How would this be achieved?

I percieve the goals of this section to be:
- provide guidance to enable devices to have a configurable means of
what networks (and applications?) it can trust and thus allow to run
- provide guidance to developers to be aware of privacy leakage and allow
for configuration but at which layer?
….but its not quite clear…

Section 3
Would agree that it is difficult to change “human” behavior….
however, I do not understand the purpose or intent of this section as I see no guidance,
consideration or recommendation.

Section 4

There are bcast/mcast protocols that may not need DNS, is the intent of
the first recommendation meant to state that protocols that offer privacy
considerations like mDNS SHOULD (or perhaps MUST) be used?  Or are you
referring to the techniques used in mDNS to enable privacy considerations?

“a broadcast/multicast protocol and cannot use an IETF-specified protocol”
IETF protocols are starting to be conscious of privacy, do you mean
protocols that do not offer privacy considerations?

“(e.g. based on the SSID)”
As requested in Section 2.5, a better definition of “safe” is required as
applications may not map to an SSID (applications may also run on different PHYs).

Other considerations
This section speaks mainly to performance issues which (1) doesn’t apply to privacy
and (2) the descriptions are limited with no salient consideration applicable to the focus
of this draft; I suggest it be removed.

Section 8
What is the intent of the 2nd paragraph?  RFC 5374 described a framework that is suited
to protect some broadcast/multicast which this paragraph notes, but what is its purpose?
Is the intent to say these mechanisms can help with privacy and if so how?

Nits:

Introduction:
“Also application
   developers use broadcast/multicast messages to implement things like
   local service or peer discovery and it appears that an increasing
   number of applications make use of it as suggested by experimental
   results obtained on campus networks including the IETF meeting
   network [TRAC2016].  That is not entirely surprising.”
[ncw] This reads awkwardly.  Suggest breaking it to something like:
“Also, application developers use broadcast/multicast messages to implement
local services.  As suggested by the experimental results documented in “How
broadcast data reveals your identity and social graph [trac2016], it is not
surprising to see the increasing trend of using these messages.”

“   Given the above, privacy protection for protocols based on broadcast
   or multicast communication is significantly more difficult compared
   to unicast communication and at the same time invading the privacy is
   much easier.”
[ncw] Do you mean privacy is even more difficult to achieve than general
data confidentiality and integrity??

Inconsistent references? “….or RFC 7919  [RFC7819])”

Section 2.2
Is there an extraneous “e.g.” in “These IDs, which e.g. identify”?
also as its the first instance of ID, call it out as “Identifiers (ID)”