Subject: [secdir] Secdir review of draft-ietf-intarea-broadcast-consider-05

From: Vincent Roca <[email-masked]>
Date: Fri, 5 Jan 2018 14:26:02 +0100

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

---

From: Rolf Winter <[email-masked]>
Date: Mon, 15 Jan 2018 20:21:28 +0100

Hi Vincent,

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:

Am 05.01.18 um 14:26 schrieb Vincent Roca:
> Summary: *Ready with issues*
> 
> *Main comments:*

Makes complete sense. I hope we have spotted all occurences in the main 
text and also changed the title accordingly:

was: "Privacy considerations for IP broadcast and multicast protocol 
designers"

new: "Privacy considerations for protocols relying on IP broadcast and 
multicast"

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

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

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

> *Clarification needed:*

Clarified.

> layer identifier voids any lower layer attempt. I'd remove this

Done.

> *Various:*

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

>          required, then the identifier SHOULD be generated randomly."

That would have not read nicely with the sentence before that. We made 
adjustments to that passage, based on this suggestion.

> *Typos:*

Nice catch.

Best,

Rolf

---

From: Vincent Roca <[email-masked]>
Date: Tue, 16 Jan 2018 09:50:26 +0100

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.

We talk about this in the security considerations section and come to the same conclusion as you do:

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.

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.

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

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

---

From: Vincent Roca <[email-masked]>
Date: Fri, 19 Jan 2018 16:10:27 +0100

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 <[email-masked]> a écrit :
> 
> Hello Rolf,
> 
> See e.g., my colleague Mathieu publication on the topic: https://hal.inria.fr/hal-00747825 <https://hal.inria.fr/hal-00747825>

---

From: Rolf Winter <[email-masked]>
Date: Fri, 19 Jan 2018 16:20:01 +0100

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:
> Summary: *Almost r**eady*
> 
>> Le 16 janv. 2018 à 09:50, Vincent Roca <[email-masked] 
>> <mailto:[email-masked]>> 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.
>>
>>> 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.
>>
>>> 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.
>>
>>> 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).
>>

---

From: Vincent Roca <[email-masked]>
Date: Fri, 19 Jan 2018 16:28:00 +0100

Hi Rolf,

What about:

OLD:

NEW:

(b)  Encryption is difficult when broadcast/multicast messages are used,
for instance because a non trivial key management protocol can be required.
When encryption is not used, the content of these messages is easily
accessible, making it easier to spoof and replay them.

Cheers,

  Vincent

> Le 19 janv. 2018 à 16:20, Rolf Winter <[email-masked]> a écrit :
> 
> Hi Vincent,
> 
> "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
> 
>>> Le 16 janv. 2018 à 09:50, Vincent Roca <[email-masked] <mailto:[email-masked]>> a écrit :
>>> 
>>> Hello Rolf,
>>>

---

From: Rolf Winter <[email-masked]>
Date: Fri, 19 Jan 2018 16:37:58 +0100

Ahh, I though you wanted more than that. A new version with that text 
suggestion has just been upload.

Thanks again,

Rolf

---

From: Vincent Roca <[email-masked]>
Date: Fri, 19 Jan 2018 16:44:24 +0100

Thanks Rolf. Version -08 answers my main comments then.
Cheers,

  Vincent

> Le 19 janv. 2018 à 16:37, Rolf Winter <[email-masked]> a écrit :
> 
> Ahh, I though you wanted more than that. A new version with that text suggestion has just been upload.
> 
> Thanks again,
> 
> Rolf
>