Re: [secdir] Secdir review of draft-ietf-intarea-broadcast-consider-07

[Rolf Winter <[e-mail]>]

Hi Vincent,

we have not forgotten about this point. You say about the text that:

"It suggests that because it’s difficult, it won’t be used. This is not 
the message the I-D should carry."

The reality today is, that it is not used, even for IETF-specified 
protocols it is mostly not specified. We still think about a good way to 
phrase it without making a point about this and then having to admit 
that the IETF itself has failed at doing it, which would be hypocitical.

Best,

Rolf

Am 19.01.18 um 16:10 schrieb Vincent Roca:
> This is a re-review. My answer below, sent on Jan. 16th,  also applies 
> to version -07.
> 
> Summary: *Almost r**eady*
> 
> 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 <[e-mail] 
>> <mailto:[e-mail]>> 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
>> 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
>