Maybe I was not clear about what I meant by “all nodes are equal”. I am talking of a scenario where every lamp in a room has a presence sensor and if any lamp detects presence it can switch on all lamps in that room or the group. The reason why the upstairs room will not be switched on due to a basement sensor is because they are two different groups (unless one wishes to achieve that particular behavior and puts them in the same group). I am not looking for any cross domain group of devices, they have to be exactly the same kind of devices with exactly the same actions.

Sent from Windows Mail

From: Michael StJohns<mailto:msj@nthpermutation.com>
Sent: ‎Tuesday‎, ‎September‎ ‎23‎, ‎2014 ‎9‎:‎24‎ ‎PM
To: dtls-iot@ietf.org<mailto:dtls-iot@ietf.org>

Your email about the security considerations section made me go back and
look.  Sorry I missed responding to this before.

On 9/23/2014 7:08 AM, Kumar, Sandeep wrote:
> I think there is more to it
> A) only confidentiality
> B) Integrity
Not integrity, but authentication.  Integrity is a service where data
isn't changed without detection between sender and receiver, not that
you know who the sender and receiver are.
>          B.1) All devices are equal in the group (all members are senders and receivers)
Can you describe a scenario where all devices in a group both send and
receive control messages AND where the identity of a sender is in all
circumstances irrelevant to the security of the system?

In prior messages, you've mentioned a system where a sensor is
incorporated within a light and/or lightswitch.   I'm pretty sure that I
care to know the identity of a sensor that fired,  I'd be pretty stupid
to turn the heat on upstairs if the sensor that fired was in the
basement.  I might also not want to increase the supply water pressure
to a house if the sensor that fired was actually a gas sensor.

The multicast security argument is not about who sends or receives, but
whether a receiver can make useful and reliable deductions about the
security environment applicable to action it should take on a received
message.

The "all nodes are equal so we can use the same key" argument makes
sense in so few domains that the only one I can consistently come up
with is a moving swarm of sensors with a very short key life and an
ability to identify and heal immediately loss of nodes and communication
compromises.  Either that or all of them have SPEs making the capture of
the multicast key effectively impossible during the life of the mesh.

Most of the argument on the list has been about trying to fit a solution
to a set of problems.  Multicast security is *very* limited in its
applicability and in most cases requires additional mitigation in the
form of SPEs, physical separation and physical security to get past the
realities of the problem.




>          B.2) There is an asymmetric relation in the devices of the group (only some members are senders)
>
> For A and B.1 symmetric crypto would be sufficient
> B.2 requires asymmetric crypto to perform authorizations.
>
> If there is no bar to stupidity then independent of whichever crypto primitive one chooses, one can always  implement things insecurely.
> Implementers can even share the same public-private key pairs on different devices(certificates are expensive) or just put the private key everywhere although the implementer should have only put the public-keys. And these kind of artificial arguments can be constructed not just for multicast security but for any protocol in IETF.

Except that BCP guidance is that symmetric keys are shared by only two,
asymmetric private keys are never shared.  Having someone pass out the
same key pairs does happen, but it's a failure of operation, not a
failure of protocol design - the protocols are designed for 2 party
symmetric not N party unlike draft-keoh which advocates N-party.   For
draft-keoh,  I can't say that the guidance given there is sufficient to
protect the purpose of a mesh if the mesh includes a function that
requires knowledge of the identity of a sender.  E.g. control of a
physical device.  I can't say the guidance given there is sufficient to
prevent implementers from adopting it past a small mesh (say 10) of
identical devices that are all equal (e.g. where's the security break
point between 5 equal nodes, 50 equal nodes and 500 equal nodes?  At
which point do you say - oops, too many and how is that enforced??)

I keep asking one thing in lots of different ways:  "How do you
constrain the protocol so it only applies to the domains to which we can
all agree are safe enough given the security limitations?" The answer is
you can't which continues to suggest that letting this out in the wild
is a bad idea.

I've made whatever points I'm going to make.

Later, Mike

>
> I think B.2 should be resolved as part of ACE.  DICE can still work on A and B.1 (with or without DTLS).
>
> Regards
> Sandeep
>
>> -----Original Message-----
>> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Ludwig Seitz
>> Sent: Tuesday, September 23, 2014 9:07 AM
>> To: dtls-iot@ietf.org
>> Subject: Re: [Dtls-iot] DTLS multicast security
>>
>> On 09/22/2014 07:46 PM, Michael StJohns wrote:
>> ....
>>> If you use multicast symmetric key systems only for confidentiality,
>>> breaking in to a node to extract the key doesn't give you much more
>>> than you already had - the multicast traffic destined for the node you
>>> just hacked.  So things like multicast audio aren't necessarily
>>> identity-important cases.
>>>
>> Aha!
>>
>> So would it be acceptable to separate the problem?
>>
>> A.) A protocol for multicast confidentiality in CoRE (with or without DTLS, I
>> don't care)
>>
>> B.) A protocol for authorizing control messages (whether they are
>> multicasted or not)
>>
>> Where this work would be done is another question, B. seems like a task for
>> ACE.
>>
>> Would A.) alone be beneficial enough to justify working on it?
>>
>> /Ludwig
>>
>>
>>
>>
>>
>> --
>> Ludwig Seitz, PhD
>> SICS Swedish ICT AB
>> Ideon Science Park
>> Building Beta 2
>> Scheelevägen 17
>> SE-223 70 Lund
>>
>> Phone +46(0)70-349 92 51
>> http://www.sics.se
>
> ________________________________
> The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.
>
> _______________________________________________
> dtls-iot mailing list
> dtls-iot@ietf.org
> https://www.ietf.org/mailman/listinfo/dtls-iot
>

_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot