Re: [Dtls-iot] DTLS multicast security

[Michael StJohns <[e-mail]>]

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:[e-mail]] On Behalf Of Ludwig Seitz
>> Sent: Tuesday, September 23, 2014 9:07 AM
>> To: [e-mail]
>> 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 [phone]
>> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtls-iot
>