Hello,

I have reviewed this document as part of the security directorate’s ongoing
effort to review all IETF documents being processed by the IESG. These
comments were written primarily for the benefit of the security area
directors.  Document editors and WG chairs should treat these comments just
like any other last call comments.

Summary: Ready with issues

This document lists recommendations concerning the use of
broadcast/multicast traffic from a privacy point of view, which is
highly valuable. However I have a certain number of comments.
(sorry if my email is a bit long…)


Main comments:

1) First of all, the focus of this document looks ambiguous.
The title refers to "IP broadcast and multicast protocol designers"
which I can understand as those low level protocols for IP broadcast
and multicast (e.g., IGMP, MLD, and why not various multicast routing
protocols, etc.). On the opposite, the abstract restricts the focus:
"application-layer protocols make use of IP broadcasts or multicast
messages" (1st sentence). Then, when reading the document, I sometimes
understand that it could also consider lower layer protocols. This
should be clarified.

Also, instead of "designers of broadcast/multicast protocols" I'd
rather say "designers of protocols relying (in parts or totally) on
broadcast/multicast traffic". This applies to the title (in a
condensed version) and throughout the core of the document.


2) Another point: I'd like to see the item (b) of introduction
developed as this is the key issue with multicast/broadcast traffic.
Without encryption, application messages are vulnerable to
eavesdropping and all kinds of analyses. A group key could be
negociated and used for encrypting this traffic, but this requires a
more complex setup mechanism (typically a key management system,
probably with re-keying and all the stuff) and requires a preliminary
association of a terminal that is not necessarily compatible with the
application-layer protocol features.
The text could say that if possible, multicast/broadcast traffic
encryption should be used, otherwise risks should be minimised as
discussed in this document. And of course, it's always good to remind
the designers that unicast traffic should be always encrypted since
there's no good reason not to do that.


3) I'd like to suggest another recommendation: when applicable, limit
or avoid user-originated broadcast/multicast messages, preferring
infrastructure originated messages.
An example: in a discovery mechanism, avoid terminal sollicitation as
much as possible and limit oneself to infrastructure announcement
broadcast messages, even if it can include some extra delay (controled
with the announcement frequency). This is exactly what happened in
Wifi AP discovery, where the passive discovery scheme, AP based, is
now prefered to the active scheme.
Said differently, multicast/broadcast is not per se the issue, when
originating from the infrastructure it is generaly safe.


4) A more general comment, related to item (a) of intro:
Broadcast/multicast can simplify user surveillance, I agree. However,
when I'm looking at all the practicies of companies working in the
advertising area (in particular A&A companies, sitting between
smartphone users and advertisers, domain that I know a little bit),
the techniques deployed are incredibly smart, some of them bypassing
technical protections set up by the OS manufacturers, others relying
on hidden technical features. It's impressive how inventive those
companies can be.
My point is that even if traffic is 100% unicast, as long as a
wireless medium is used, anyone wanting to monitor users in order to
profile them will set up the required hardware/software configuration.
This is trivial and extremely cheap nowadays (except perhaps for 4G
connections), and most of the time this is a purely passive
monitoring. The unicast/multicast/broadcast nature of traffic has no
importance as long as you are within wireless network range.


Clarification needed:

** section 4: I cannot understand the meaning of "information" in:
        "* You SHOULD try to design the protocol in a way that the
         information cannot be correlated with other information in
         broadcast/multicast messages"
What does the first instance of "information" refer to?


** Last but one sentence of section 2.2: Why do you say "or at least
much more difficult"? Without encryption, a persistant application
layer identifier voids any lower layer attempt. I'd remove this
comment altogether.


Various:

** the authors use the term "host name" to refer to a higher layer
name of a device. To me this term refers to the DNS notion of
"hostname", i.e. something different, hence confusion. I'd recommend
to use "device name" in order to avoid it.

** section 2.3: instead of:
        "If only a persistent ID is needed, this can be generated
        randomly. »
I'd rather say:
        "Persistent identifiers SHOULD be avoided (section 2.2), but
        if one is absolutely needed and if the devide name is not
        required, then the identifier SHOULD be generated randomly."


Typos:

** section 4: s/broad-/broadcast/ in:
        "because of the special nature of broad- and multicast."

** section 5: "are" is missing in:
        ...for another class of attacks that not related to privacy."


Regards,

  Vincent