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

From: Rolf Winter <[email-masked]>
Date: Tue, 24 Oct 2017 17:36:48 +0200

Hi,

thanks for the review and sorry for the belated reply. Please see 
comments inline.

Am 26.09.17 um 00:57 schrieb Nancy Cam-Winget (ncamwing):
> 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.

The document focusses on cases where multicast is used in an unmanaged 
fashion, i.e. there is no authentication and authorization in place that 
can readily be used, see section 1.1 of the document. A tightly managed 
environment where authentication and authorization in place is not the 
target scenario. And most apps cannot really rely on something like this 
and use e.g. the all nodes addesses, broadcast or the local network 
control block.

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

There is that, but there is a real concern that protocols developed 
outside the IETF which we see on networks today pose a risk to privacy. 
We wanted to make clear that this document is addressing people outside 
the IETF. We can reduce some text about that but I do not understand why 
that text is a concern. I would suggest to make a separate paragraph out 
of it, separating it from the reference to RFC6973. Would that work?

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

I guess most accurate would be frequency and duration.

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

No, it really means "in case it is changing". There is work ongoing to 
implement MAC address or IP address randomization. But if a 
broadcast/multicast protocol is using persistent identifiers, then a 
passive observer can deduce that the MAC address has changed, because 
the application layer identifier is still the same. In other words, this 
might actually break the efforts on lower layers.

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

Could you give an example where this does not work, then we can address 
your concern. This is unique to broadcast/multicast, because a passive 
obserser sees this. In unicast traffic you need to be on-path to observe 
this, which is a special requirement and much harder to achieve (when 
you are on-path many more things are possible anyway).

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

I would disagree. Awareness is a recommendation that you cannot really 
enforce.

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

The following paragraphs do not suffice as examples?

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

Since the document addresses application developers, the probelmatic 
bits are in the application layer really.

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

It should make the developer aware, that existing applications have 
means to make the privacy thread less pronounced. Binding the feature to 
a particular network, allowing the user to switch it off etc. are some 
of the things a developer should make possible.

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

Well, the IETF cannot recommend things to OS vendors, regular users etc. 
and add a SHOULD or even a MUST. That does not make sense, but in order 
to be complete, that section mentions that there are operational means 
to alleviate the privacy problems. The section is really for 
completeness sake.

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

It really means that the protocols should be used. I cannot quite read 
it any other way.

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

No, if e.g. IETF-specified protocols do not offer needed functionality 
and one has to implement a new proprietary protocol.

> 
> “*(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).

This is only to be seen as one example as the e.g. indicates.

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

We can, this was also just for completeness sake.

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

It's purpose is what you basically asked at the very beginning of your 
review, you can protect multicast but that is not a generally applicable 
thing.

> *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)”
> 

The e.g. is needed because there might be other uses for those IDs.

Thanks,

Rolf