Re: [Dtls-iot] DTLS multicast security

[Sye Loong Keoh <[e-mail]>]

Hi Dorothy,

Me too, I certainly support DICE to continue pursuing option A.

Many thanks
Sye Loong

From: dtls-iot [mailto:[e-mail]] On Behalf Of Dorothy Gellert
Sent: Wednesday, 24 September, 2014 1:23 AM
To: [e-mail]
Cc: Michael StJohns
Subject: Re: [Dtls-iot] DTLS multicast security

Hi All,

Ok,  I think we have found a way forward.     Mike,  I have you on record for drafting a " pretty restrictive, pretty blunt security considerations section".

Can I confirm support from those who have responded to the consensus call, specifically, that we pursue A) Protocol for multicast confidentiality in CoRE?

Thanks,
Dorothy







On Sep 23, 2014, at 9:49 AM, Michael StJohns <[e-mail]<mailto:[e-mail]>> wrote:


On 9/23/2014 3:07 AM, Ludwig Seitz wrote:

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


This above is pretty much where I think we're at.  The only scenario proposed for draft-keoh is a control protocol for lightbulbs.  It's unclear that there is sufficient need for confidentiality there to justify sending the proposal forward.  The protocol doesn't meet the needs (or at least what *I* think are the needs) for being used to authenticate and authorize changes in the physical world.

I pushed back on this suggesting that CoAP figure out how to sign its control messages asymmetrically, and then how to multicast them (not DTLS, not DTLS multicast, just basic IP multicast over UDP probably) to get the effect they want.  The push back to the push back is the "cost" and latency of verifying such a message at an IOT node.  Physics of cryptography colliding with cost.  The problem is as I've noted elsewhere - this protocol has to work for more than just this one scenario - and it has to be secure for those scenarios.  It's not even minimally secure for this one.

With respect to doing draft-keoh only for confidentiality - I'd draft a pretty restrictive, pretty blunt security considerations section sufficient for any company to get into liability hell if they ever attempted to use the keys for control actions and something bad happens.  I did something similar for RFC1413.  That said, we'd need at least a few other scenarios where multicast meets a confidentiality need on the IOT space.

Later, Mike


ps -

I wanted to slightly expand the confidentiality multicast thing. For most high value multicasted content (e.g. think satellite video), there are secure processing elements at each of the receiving node designed to prevent the compromise of the stream key (which changes very frequently).  In addition to that there are SPEs designed to keep the decrypted stream PDUs from being disclosed prior to rendering as pixels and audio wave forms, and to prevent capture of the PDUs for recording. So even when confidentiality is desired, there may be a need for additional implementation requirements over and above what the protocol can provide.  With control multicast, you really start out requiring either asymmetric or an SPE to make it secure enough. /msj/


_______________________________________________
dtls-iot mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dtls-iot