Telechat Review of draft-ietf-intarea-broadcast-consider-07
review-ietf-intarea-broadcast-consider-07-secdir-telechat-roca-2018-01-25-00

This is a re-review. My answer below, sent on Jan. 16th,  also applies to
version -07.

Summary: Almost ready

Most of my initial comments have been addressed by the authors.

I made a few suggestions/clarifications (below), in addition to my initial
review.

I would insist on implementing the first one, 2), beginning with:
        "I’d like you extend a little the the bullet (b) of introduction: … »

but let the authors judge what they prefer to do for the next ones.

Regards,

  Vincent

> Le 16 janv. 2018 à 09:50, Vincent Roca <vincent.roca@inria.fr> a écrit :
>
> Hello Rolf,
>
>> thanks for the detailed review and sorry for the belated reply. We have
submitted a new version based on these comments and recommendations. Please see
inline: > > You’re welcome. > >>> 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. >> >> >> We talk about this in the security
considerations section and come to the same conclusion as you do: >> >> "It
should be noted that certain applications could make use of >>   existing
mechanisms to protect multicast traffic such as the ones >>   defined in
[RFC5374].  Examples of such applications can be found in >>   Appendix A. of
[RFC5374].  Given the required infrastructure and >>   assumptions about these
applications and the security infrastructure, >>   many applications will not
be able to make use of such mechanisms." >> >> In which way would you expand on
this? > > I’d like you extend a little the the bullet (b) of introduction: >
(b) Encryption is more difficult when broadcast/multicast messages, >        
leaving content of these messages in the clear and making it >         easier
to spoof and replay them. > It suggests that because it’s difficult, it won’t
be used. This is not the > message the I-D should carry. It’s difficult (add a
reference here), sure, > but not impossible. You can also briefly explain why
it’s more difficult with > multicast/broadcast. > > >>> 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. >> >> I think I disagree somewhat (and it is not a generally
applicable use case, e.g. if resources on a host are offered there is no
general way to delegate announcements of these to the infrastructure). Saying
that infrastructure announcements are generally safe requires that a receiver
can validate that a message came from the infrastructure which is a problem
(e.g. rogue DHCP servers). A lot of deployments solve some of this through
infrastructure means (e.g. DHCP snooping), but we have documented that. Also,
whatever comes from the infrastructure requires a standard so that devices/apps
understand it. We have text around that, too. > > Let me clarify what I had in
mind. A few years ago, discovery of a known WiFi AP > from a device was
accelerated through the use of an active mechanism, with the > device sending
probes to potentially detects those know WiFi APs. That was > awful from a
privacy point of view as highlighted by researchers. The trend was to > move to
a passive approach, relying mostly on AP announcements (in addition to > MAC
address randomisation). The privacy benefits while doing so are terrible. > See
e.g., my colleague Mathieu publication on the topic:
https://hal.inria.fr/hal-00747825 <https://hal.inria.fr/hal-00747825> > This is
perfectly in line with your  I-D. How privacy can be compromised by using > a
broadcast based protocol. > > Having said that, I agree with you that rogue
announcements raise security concerns > (but that’s true for any message sent),
and it does not work for resources offered by > a host. I agree, this is not a
universal approach. I let you judge whether it makes sense > to talk about it
or not. > > >>> 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.
>> >> >> I think there is little that the IETF can do about that. Also
"bypassing technical protection" and using "hidden technical features" is
nothing you can protect against in general and I assume is often not by design.
> > I agree and I don’t want to question the importance of this I-D here. > But
it remains that wireless communications are so easy to monitor. > > >>>
*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. >> >> Well, RFC 7719 even admits the term
is ill defined and does refer to various things. Also, for the protocols we
looked at and OS configurations, sometimes there are different host namens
being used for different purposes. We would like to stick with host names (also
since RFC8117 useses the term which is highly relevant in this context). > > I
was not aware of those RFCs. Do what you believe is the most appropriate. > >
Cheers, > >    Vincent