Subject: [Dtls-iot] DTLS multicast security

From: Dorothy Gellert <[email-masked]>
Date: Thu, 18 Sep 2014 13:41:06 -0700

Dear WG,

Last week our AD and the WG chairs, myself and Zach, met to discuss the progress of the DTLS multicast security Work Item. 
it seems as though we have reach an impasse with regards to the issues raised on the mailing list with multicast security and DTLS.     

If this is the consensus of the WG  we can progress the WG without this Work item and move forward with the other 2 work items, the dtls profile and practical issues around the DTLS handshake.   

I’d like to request feedback from the WG on this plan.

Thanks, 
Dorothy

---

From: Ludwig Seitz <[email-masked]>
Date: Fri, 19 Sep 2014 08:44:48 +0200

> I’d like to request feedback from the WG on this plan.

When making a decision on this, please note that secure multicast would 
be considered a considerable benefit by some. See e.g. 
http://www.ietf.org/mail-archive/web/ace/current/msg00826.html

Regards,

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

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 19 Sep 2014 11:14:08 +0000

Hi Dorothy

Agree that we have an impasse based on two different opposing views within the working group on how good a particular solution is for solving the security for draft-ietf-core-groupcomm.  I think it would be unwise to drop this work item based on disagreement on one particular solution. I would prefer that we delay the milestone for a later date so that alternative solutions can be presented by others. In the meantime we can indeed focus on the other topics which are hopefully less controversial while we get more data points on how and where multicast will be used in different IoT applications.

Regards
Sandeep

> -----Original Message-----
> From: dtls-iot [mailto:[email-masked]] On Behalf Of Dorothy
> Gellert
> Sent: Thursday, September 18, 2014 10:41 PM
> To: [email-masked]
> Subject: [Dtls-iot] DTLS multicast security
>
> Dear WG,
>
> Last week our AD and the WG chairs, myself and Zach, met to discuss the
> progress of the DTLS multicast security Work Item.
> it seems as though we have reach an impasse with regards to the issues
> raised on the mailing list with multicast security and DTLS.
>
> If this is the consensus of the WG  we can progress the WG without this Work
> item and move forward with the other 2 work items, the dtls profile and
> practical issues around the DTLS handshake.
>
> I'd like to request feedback from the WG on this plan.
>
> Thanks,
> Dorothy
>
>
>
>
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 19 Sep 2014 11:27:48 +0000

Hi Dorothy,

I agree with Ludwig that having a secure multicast is considered a benefit by many.  For example, during the recent IESG review of the base CoAP Group Communication spec there were several comments made by AD's reflecting the need for a secure multicast solution to be developed by IETF.  See for example:

http://www.ietf.org/mail-archive/web/core/current/msg05566.html

	"The lack of security controls is an issue, experimental
	would be good until it is resolved as there is a lot of work to be done
	in this space and it is active."

So, I think we still need to have a Work Item to develop a secure group communication solution.  However, perhaps we can modify the description of the Work Item and not have it exclusively linked to a DTLS-based approach for secure group communication.  We should allow for other approaches if people want to propose them.  But we should still definitely keep working on this topic (i.e. secure group communication).

A separate thought is that we may also want to progress the existing http://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/ but put it on an Experimental track.  That way we can get experience with the solution but not put it directly on Standards track.   

Best Regards,

Akbar

-----Original Message-----
From: dtls-iot [mailto:[email-masked]] On Behalf Of Ludwig Seitz
Sent: Friday, September 19, 2014 2:45 AM
To: [email-masked]
Subject: Re: [Dtls-iot] DTLS multicast security

> I'd like to request feedback from the WG on this plan.

When making a decision on this, please note that secure multicast would be considered a considerable benefit by some. See e.g. 
http://www.ietf.org/mail-archive/web/ace/current/msg00826.html

Regards,

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

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 11:01:01 -0400

On 9/19/2014 7:27 AM, Rahman, Akbar wrote:
> Hi Dorothy,
>
>
> I agree with Ludwig that having a secure multicast is considered a benefit by many.
My problem with this statement is that I would consider anti-gravity to 
be a benefit to many, but that AG has exactly the same scientific basis 
as symmetric key multicast security - none.  There's long, long 
experience on this topic that the document writers have ignored.

>    For example, during the recent IESG review of the base CoAP Group Communication spec there were several comments made by AD's reflecting the need for a secure multicast solution to be developed by IETF.  See for example:
>

I think you're misrepresenting that message.  It's by Kathleen 
Moriarty.  She notes the lack of security in the body of the message, 
but the comment on "experimental" isn't on security specifically, but on 
the whole idea of CoAP group communications. Cf the other messages which 
object to the document as informational without mentioning security.

> So, I think we still need to have a Work Item to develop a secure group communication solution.  However, perhaps we can modify the description of the Work Item and not have it exclusively linked t…

There's two things here:  1) The group is supposed to be profiling work 
done elsewhere to shrink it for use with IOT, not creating new stuff; 2) 
My objections to secure multicast are specifically in the area of the 
use of multicast as a control protocol; symmetric key systems are NOT 
secure enough for control systems and there appears to be deep and 
abiding resistance to the use of asymmetric systems (e.g. signed control 
messages) leading us to an impasse.

I agree that DTLS is probably not the appropriate protocol for signed 
control messages, but there also seems to be a deep and abiding 
resistance to adding it to CoAP where it might make the most sense.

Dorothy has proposed the withdrawal of multicast DTLS and I think that's 
the correct decision.   If someone wants to propose an asymmetric system 
that works with CoAP and run it through this group, I won't object (but 
the AD's might given the current charter).

> A separate thought is that we may also want to progress the existing http://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/ but put it on an Experimental track.  That way we can get ex…

Instead, place it as a company informational like hundreds of other 
documents.  Philips can provide experimental results in a year or so.  
There's only a reason to place it on the experimental track if more than 
one company is planning on using it and modifying it.

Later, Mike

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 19 Sep 2014 15:15:43 +0000

Hi Mike,

>My problem with this statement is that I would consider anti-gravity to be a benefit to many, but that AG has exactly the same scientific basis as symmetric key multicast security - none.  There's long, long experience on this topic that the document writers have ignored.

I did not refer to any document in my statement above.  (Neither did I reference a specific approach like symmetric key).   I simply said that "secure multicast" is considered beneficial.  Actually, I challenge you to point out any references that advocate unsecure multicast for IoT related use cases.

Best Regards,

Akbar

-----Original Message-----
From: dtls-iot [mailto:[email-masked]] On Behalf Of Michael StJohns
Sent: Friday, September 19, 2014 11:01 AM
To: [email-masked]
Subject: Re: [Dtls-iot] DTLS multicast security

> I agree with Ludwig that having a secure multicast is considered a benefit by many.
My problem with this statement is that I would consider anti-gravity to be a benefit to many, but that AG has exactly the same scientific basis as symmetric key multicast security - none.  There's long, long experience on this topic that the document writers have ignored.

> 	in this space and it is active."

I think you're misrepresenting that message.  It's by Kathleen Moriarty.  She notes the lack of security in the body of the message, but the comment on "experimental" isn't on security specifically, but on the whole idea of CoAP group communications. Cf the other messages which object to the document as informational without mentioning security.

> So, I think we still need to have a Work Item to develop a secure group communication solution.  However, perhaps we can modify the description of the Work Item and not have it exclusively linked t…

There's two things here:  1) The group is supposed to be profiling work done elsewhere to shrink it for use with IOT, not creating new stuff; 2) My objections to secure multicast are specifically in the area of the use of multicast as a control protocol; symmetric key systems are NOT secure enough for control systems and there appears to be deep and abiding resistance to the use of asymmetric systems (e.g. signed control
messages) leading us to an impasse.

I agree that DTLS is probably not the appropriate protocol for signed control messages, but there also seems to be a deep and abiding resistance to adding it to CoAP where it might make the most sense.

Dorothy has proposed the withdrawal of multicast DTLS and I think that's 
the correct decision.   If someone wants to propose an asymmetric system 
that works with CoAP and run it through this group, I won't object (but the AD's might given the current charter).

> A separate thought is that we may also want to progress the existing http://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/ but put it on an Experimental track.  That way we can get ex…

Instead, place it as a company informational like hundreds of other documents.  Philips can provide experimental results in a year or so.  
There's only a reason to place it on the experimental track if more than one company is planning on using it and modifying it.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 11:19:43 -0400

On 9/19/2014 11:15 AM, Rahman, Akbar wrote:
> Actually, I challenge you to point out any references that advocate unsecure multicast for IoT related use cases.

http://datatracker.ietf.org/doc/draft-ietf-core-groupcomm/

Seriously - that was way too easy.   Although "advocate" may be too 
strong, that document defers security to a later time.

---

From: "Rahman, Akbar" <[email-masked]>
Date: Fri, 19 Sep 2014 15:22:39 +0000

Yes, and the time to solve it is now.  And this WG was chartered to do it.

So perhaps better to stop playing Catch-22.  But if there is absolutely no interest in doing it in this WG then that is an honorable outcome as well.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Sep 2014 17:44:37 +0200

> My problem with this statement is that I would consider anti-gravity to be a benefit to many, but that AG has exactly the same scientific basis as symmetric key multicast security - none.  There's…

This discussion is a great demonstration that the IETF is unfit to do appropriate security.

Yes, there is no known way to do efficient multicast security at military security levels*).

I’m not interested in military security.
The use cases I’m interested in need neither nonrepudiation nor do they need to address a threat model that involves tampering with devices.

draft-mglt-dice-ipsec-for-application-payload demonstrates that we already have the IETF protocols in place to do appropriate security here.

All the various Philips proposals tried to do was to package this functionality in a way that fits better to the other security protocols that DICE is trying to improve.  (And, yes, that work wasn’t finished before it was derailed.)

If we cannot continue this work because it wouldn’t solve other use cases we don’t care about, that would be rather disappointing.

Grüße, Carsten

*) TESLA is not solving our problem either.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 11:48:23 -0400

> So perhaps better to stop playing Catch-22.  But if there is absolutely no interest in doing it in this WG then that is an honorable outcome as well.

In my past life I was program manager at ARPA/DARPA.  I funded about 
$2-3M of research in multicast security (including funding the work for 
GKMP/GSAKMP - RFC2034 and its descendents).

The conclusions that research came to were:  1) symmetric key systems 
provided some amount of confidentiality for multicast without additional 
risk; 2) symmetric key systems were not secure enough for 
multicast-based control systems absent the use of secure processing 
elements; 3) asymmetric key systems were needed for secure multicast if 
you didn't have secure processing elements at ALL nodes within the 
multicast group.

In the years since then, nothing I've seen controverts those conclusions.

Note that the item (1) assumes that compromise of the node gives you 
access to the communications, so compromise of the group key via the 
node is no worse than compromise of the node - that is not the case if 
the group key is being used (2) for control.

Note that (2) requires an SPE to prevent the extraction of the group key 
material and to prevent misuse of the group key material (e.g. an SPE 
enforces that a non-control node can't mark traffic as being control 
traffic).

This isn't catch 22 - this is physics.  The physics says 1, 2 and 3 as 
above.  If you want to solve this with reference to those conditions, 
then we can make progress.  If you don't, then we can't.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 12:00:54 -0400

> *) TESLA is not solving our problem either.

Carsten - if we could constrain the use of whatever we came up with to a 
group of 10-12 lightbulbs inside someone's home, I'd say go ahead.  But 
this will end up as a general IOT cyber-physical control protocol.  It 
*will* be used on other things and it will be hacked.   Those are my 
assumptions - they may be wrong, but they are the most responsible 
assumptions to make when considering the protocol design.    This isn't 
military security, but it is security necessary when the internet 
impinges on and controls the physical world.

Later, Mike

---

From: Nelson B Bolyard <[email-masked]>
Date: Fri, 19 Sep 2014 09:07:59 -0700

On 2014/09/19 09:00 PDT, Michael StJohns wrote:
> [...] if we could constrain the use of whatever we came up with to a 

Agreed.

/Nelson Bolyard

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Sep 2014 18:18:06 +0200

On 19 Sep 2014, at 18:00, Michael StJohns <[email-masked]> wrote:

> Carsten - if we could constrain the use of whatever we came up with to a group of 10-12 lightbulbs inside someone's home, I'd say go ahead.  But this will end up as a general IOT cyber-physical control protocol.  It *will* be used on other things and it will be hacked.   Those are my assumptions - they may be wrong, but they are the most responsible assumptions to make when considering the protocol design.    This isn't military security, but it is security necessary when the internet impinges on and controls the physical world.

Absent such a protocol, people will use unsecured multicast with some perimeter protection.
I do not believe that is a better situation.

The position you take is that it is never right to develop a protocol for appropriate security because there will always be someone using the protocol outside its area of application.  I have no idea how we could embark on the opportunistic security train if that is a tenable position.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 12:35:18 -0400

> The position you take is that it is never right to develop a protocol for appropriate security because there will always be someone using the protocol outside its area of application.  I have no id…
Carsten -

Absent such a protocol, people will use multicast for control secured 
with asymmetric signatures which is wholesale secure as long as the 
private key is secure.   Don't give me false either/or arguments.

The position I take is that you never deploy things that have the 
potential to make things worse.  In the opportunistic model you 
reference, you're adding confidentiality (maybe integrity, not 
authetication) and changing the work factor for an attacker from passive 
monitoring to active attack.  AFAICT, you're not increasing the exposure 
of either end of the communication except by the possible false sense of 
security (e.g. still vulnerable to MITM attacks, but may be oblivious to 
that, but that's no worse than the unencrypted case so....)

In the symmetric key multicast system without an SPE, compromise of a 
single node either physically or over the air is sufficient to 
compromise (wholesale compromise) the mesh and provide control keys to 
the attacker.

Later, Mike

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 19 Sep 2014 16:38:58 +0000

Hi Mike

It would be really nice if you could also reference the documents that conclude 1, 2, 3. It is important to also understand the context in which this research was done considering the 'D' in the organization name, I am sure it was not the IoT. I haven't seen any proposal to use public key for every multicast message proposed for even the more powerful  internet nodes. GKMP/GSAKMP as far as I remember is about single group keys and all its descents always mentioned how to use group keys for IPSec.

Regards
Sandeep

>
> In my past life I was program manager at ARPA/DARPA.  I funded about $2-
> 3M of research in multicast security (including funding the work for
> provided some amount of confidentiality for multicast without additional risk;
> 2) symmetric key systems were not secure enough for multicast-based
> control systems absent the use of secure processing elements; 3)
> asymmetric key systems were needed for secure multicast if you didn't have
> secure processing elements at ALL nodes within the multicast group.
>
> access to the communications, so compromise of the group key via the node
> is no worse than compromise of the node - that is not the case if the group
> key is being used (2) for control.
>
> enforces that a non-control node can't mark traffic as being control traffic).
>
> This isn't catch 22 - this is physics.  The physics says 1, 2 and 3 as above.  If you
> want to solve this with reference to those conditions, then we can make
> progress.  If you don't, then we can't.
>
> Later, Mike
>
>
>
> >
> >
> >> Actually, I challenge you to point out any references that advocate
> unsecure multicast for IoT related use cases.

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 19 Sep 2014 18:58:22 +0200

On 19 Sep 2014, at 18:35, Michael StJohns <[email-masked]> wrote:

> Absent such a protocol, people will use multicast for control secured with asymmetric signatures which is wholesale secure as long as the private key is secure.   

You know different people than I do...

> The position I take is that you never deploy things that have the potential to make things worse. 

Exactly: appropriate security can take this use case from perimeter “security” to something better.

The important observation here is that the absolutes you are stating aren’t:
You are trying to predict how human behavior is influenced by the availability of additional courses of action, and that isn’t going to work with humans and environments you don’t know.

Oh, and you think OS is always making things better?
Boss: Is the data going to be encrypted?
Dev: Sure, with AES-256 and OS.
Boss: I don’t know which OS you are using, but AES-256 sounds good. Then go ahead and ship the company data over that insecure network...

Grüße, Carsten

---

From: Dorothy Gellert <[email-masked]>
Date: Fri, 19 Sep 2014 09:59:11 -0700

Hi Ludwig,

Thank you for the response.   There is no doubt that a secure multicast in an IOT environment is needed.  The issue with respect to our chartered Work item is if the DTLS record layer is the right place from a security standpoint to accomplish this?

-Dorothy

On Sep 18, 2014, at 11:44 PM, Ludwig Seitz <[email-masked]> wrote:

> When making a decision on this, please note that secure multicast would be considered a considerable benefit by some. See e.g. http://www.ietf.org/mail-archive/web/ace/current/msg00826.html
> 
> Regards,
> 
> 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
>

---

From: Dorothy Gellert <[email-masked]>
Date: Fri, 19 Sep 2014 10:10:25 -0700

HI Mike-

What we want to do as Chairs is to reach consensus on how to progress the work items.   If there consensus to drop the work item,  that would be progress. 

If the consensus of the group is to rework the Charter Item, so that it does not depend on DTLS, we can also do that.    So far there is willingness to re-work the charter item. 

Can we get more feedback from the WG?

Thanks,
Dorothy

On Sep 19, 2014, at 8:01 AM, Michael StJohns <[email-masked]> wrote:

> There's two things here:  1) The group is supposed to be profiling work done elsewhere to shrink it for use with IOT, not creating new stuff; 2) My objections to secure multicast are specifically in the area of the use of multicast as a control protocol; symmetric key systems are NOT secure enough for control systems and there appears to be deep and abiding resistance to the use of asymmetric systems (e.g. signed control messages) leading us to an impasse.
> 
> Dorothy has proposed the withdrawal of multicast DTLS and I think that's the correct decision.   If someone wants to propose an asymmetric system that works with CoAP and run it through this group, I won't object (but the AD's might given the current charter).
> 
>> 
> Instead, place it as a company informational like hundreds of other documents.  Philips can provide experimental results in a year or so.  There's only a reason to place it on the experimental track if more than one company is planning on using it and modifying it.
> 
> Later, Mike
> 
> 
>> 
>> 
>> Best Regards,
>> 
>> 
>> Akbar
>>

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 13:18:16 -0400

On 9/19/2014 12:38 PM, Kumar, Sandeep wrote:
> Hi Mike
>
> It would be really nice if you could also reference the documents that conclude 1, 2, 3.
Hmmm... let me see if I can find 28-30 year old research papers and 
reports....    it really is true that those who ignore history are 
doomed to repeat it.

>   It is important to also understand the context in which this research was done considering the 'D' in the organization name, I am sure it was not the IoT.
It's more important to understand the context in which multicast 
security is going to be used.   The two contexts of importance are 
control and non-control.  (Or rather identity important vs identity not 
important).

> I haven't seen any proposal to use public key for every multicast message proposed for even the more powerful  internet nodes. GKMP/GSAKMP as far as I remember is about single group keys and all its descents always mentioned how to use group keys for IPSec.

Yup.  Can you find any of those documents which discuss and recommend 
symmetric key multicast IPSEC for control traffic? Instead, GSAKMP 
(RFC4535) has "GSAKMP does not provide identity protection.", RFC 4046 
has (Underline/bold mine):

        6.2.4 <http://tools.ietf.org/html/rfc4046#section-6.2.4>.
        Authentication Key

    The GCKS provides a symmetric or public key for authentication of its
    rekey messages.*_Symmetric key authentication is appropriate only
    when all group members can be trusted not to impersonate the GCKS._*
    The architecture does not rule out methods for deriving symmetric
    authentication keys at the member [RFC2409  <http://tools.ietf.org/html/rfc2409>] rather than pushing them
    from the GCKS.

The whole thing about non-control multicast is that all nodes are 
somewhat equivalent in their threat models.  Each node gets all the 
traffic so compromise of the multicast key is no worse than compromise 
of any given node and vice versa.  Basically, getting access to the key 
is a side effect of getting access to the node's received traffic.  
That's why using multicast symmetric keys for confidentiality is not a 
lose. (case 1)

Conversely, in control multicast nodes are divided into control and 
actuator nodes.  In a good system, you'd need to compromise a control 
node to compromise the mesh control function, but in symmetric key 
control multicast compromise of any node is sufficient to compromise the 
mesh control function. (case 2)

Again, write this as non-control, confidentiality only symmetric key 
multicast, agree to have a "thou shalt not" use the multicast symmetric 
keys as authentication/authorization in the document and point to 
asymmetric systems for control functions and we can go forward. (case 
3)  In fact, profile either GSAKMP or rfc 4046 along those lines.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 13:45:41 -0400

> You know different people than I do...

Not necessarily, but when refuting an either/or argument, its 
appropriate to provide a third/fourth/fifth alternative.

> You are trying to predict how human behavior is influenced by the availability of additional courses of action, and that isn’t going to work with humans and environments you don’t know.

Fair point.  But I can do "worst case analysis" and look at whether or 
not there's a way to do things to avoid said worst case.  Not using 
symmetric keys for control purposes in multicast avoids worst case.  
It's really just that simple.

> Boss: I don’t know which OS you are using, but AES-256 sounds good. Then go ahead and ship the company data over that insecure network...

I like it when you make my arguments for me:

Best Result:
Boss:  We need to set up all of the doors in the company so they can be 
controlled remotely.
Dev:  There's this protocol CoAP - it can be used to multicast messages 
to open and close such doors.
Boss: Is it secure?
Dev:  No
Boss:  Then we should probably not use it.

- or -

Fail:
Boss:  We need to set up all of the doors in the company so they can be 
controlled remotely.
Dev:  There's this protocol CoAP - it can be used to multicast messages 
to open and close such doors.
Boss: Is it secure?
Dev:  Yes, it implements Draft-keoh and uses 128 bit AES
Boss: Then let's use it.
Hacker: (rubs hands) Excellent, they implement draft-keoh and one of the 
nodes is a light bulb outside the physical control area.

- or -

Epic Fail:
Boss:  We need to set up all doors of this prison so they can be 
controlled remotely.
Designer:  There are these devices that plug into the internet that are 
"secure" and cheap.  We can buy them and install them quickly.
Boss:  How secure are they?
Designer:  How would I know - but they wouldn't sell them as secure 
unless they were would they?
Boss:  Well that's OK, it's only a medium security prison after all and 
we'll make a lot more profit this way.

Like it or not, the imprimatur of "its got security" has issues beyond 
the security community.  In OS the choice was between sending stuff 
without confidentiality and with confidentiality, not between sending 
stuff and not sending stuff.  I don't actually like it all that much, 
but there isn't a lot of downside.

---

From: Michael StJohns <[email-masked]>
Date: Fri, 19 Sep 2014 13:55:13 -0400

On 9/19/2014 1:10 PM, Dorothy Gellert wrote:
> HI Mike-
>
> What we want to do as Chairs is to reach consensus on how to progress 
> the work items.   If there consensus to drop the work item,  that 
> would be progress.
>
> If the consensus of the group is to rework the Charter Item, so that 
> it does not depend on DTLS, we can also do that.    So far there is 
> willingness to re-work the charter item.
>

Hi Dorothy -

My preference is to remove this entirely from the WG - I don't think its 
a good fit for DTLS.

If the group wants to do asymmetric control multicast either at CoAP or 
as a profile of one of the other existing multicast protocols, I 
wouldn't resist modifying the charter to do the work here.

If the group continues to want to do symmetric control multicast, I 
would continue to argue strongly against doing it here (or for that 
matter anywhere in the IETF) for all of the reasons I've reiterated many 
times.

Later, Mike

>
> Thanks,
> Dorothy
>
>
> On Sep 19, 2014, at 8:01 AM, Michael StJohns <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> My problem with this statement is that I would consider anti-gravity 
>> to be a benefit to many, but that AG has exactly the same scientific 
>> basis as symmetric key multicast security - none.  There's long, long 
>>>   For example, during the recent IESG review of the base CoAP Group 
>>> Communication spec there were several comments made by AD's 
>>> reflecting the need for a secure multicast solution to be developed 
>>> by IETF.  See for example:
>>>
>> but the comment on "experimental" isn't on security specifically, but 
>> on the whole idea of CoAP group communications. Cf the other messages 
>> which object to the document as informational without mentioning 
>> security.
>>
>>>
>>>
>>> So, I think we still need to have a Work Item to develop a secure 
>>> group communication solution.  However, perhaps we can modify the 
>>> description of the Work Item and not have it exclusively linked to a 
>>> DTLS-based approach for secure group communication.  We should allow 
>>> for other approaches if people want to propose them.  But we should 
>>> still definitely keep working on this topic (i.e. secure group 
>>> communication).
>>
>> There's two things here:  1) The group is supposed to be profiling 
>> work done elsewhere to shrink it for use with IOT, not creating new 
>> stuff; 2) My objections to secure multicast are specifically in the 
>> area of the use of multicast as a control protocol; symmetric key 
>> systems are NOT secure enough for control systems and there appears 
>> to be deep and abiding resistance to the use of asymmetric systems 
>> (e.g. signed control messages) leading us to an impasse.
>>
>> Dorothy has proposed the withdrawal of multicast DTLS and I think 
>> that's the correct decision.   If someone wants to propose an 
>> asymmetric system that works with CoAP and run it through this group, 
>> I won't object (but the AD's might given the current charter).
>>
>>>
>>> A separate thought is that we may also want to progress the 
>>> existinghttp://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/but 
>>> put it on an Experimental track.  That way we can get experience 
>>> with the solution but not put it directly on Standards track.
>>
>>  There's only a reason to place it on the experimental track if more 
>> than one company is planning on using it and modifying it.
>>
>> Later, Mike
>>
>>
>>>
>>>
>>> Best Regards,
>>>
>>>
>>> Akbar
>>>
>>> To: [email-masked] <mailto:[email-masked]>
>>>> Last week our AD and the WG chairs, myself and Zach, met to discuss 
>>>> the progress of the DTLS multicast security Work Item.
>>>> it seems as though we have reach an impasse with regards to the 
>>>> issues raised on the mailing list with multicast security and DTLS.
>>>>
>>>> If this is the consensus of the WG  we can progress the WG without 
>>>> this Work item and move forward with the other 2 work items, the 
>>>> dtls profile and practical issues around the DTLS handshake.
>>>>
>>> When making a decision on this, please note that secure multicast 
>>> would be considered a considerable benefit by some. See e.g.
>> [email-masked] <mailto:[email-masked]>

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Fri, 19 Sep 2014 18:05:47 +0000

Hi Mike

It would be really nice if you could also reference the documents that conclude 1, 2, 3.
Hmmm... let me see if I can find 28-30 year old research papers and reports....    it really is true that those who ignore history are doomed to repeat it.

 It is important to also understand the context in which this research was done considering the 'D' in the organization name, I am sure it was not the IoT.
It's more important to understand the context in which multicast security is going to be used.   The two contexts of importance are control and non-control.  (Or rather identity important vs identity not important).

Yup.  Can you find any of those documents which discuss and recommend symmetric key multicast IPSEC for control traffic?   Instead, GSAKMP (RFC4535) has "GSAKMP does not provide identity protection.", RFC 4046 has (Underline/bold mine):
6.2.4<http://tools.ietf.org/html/rfc4046#section-6.2.4>.  Authentication Key

   rekey messages.  Symmetric key authentication is appropriate only

   when all group members can be trusted not to impersonate the GCKS.

   authentication keys at the member [RFC2409<http://tools.ietf.org/html/rfc2409>] rather than pushing them

   from the GCKS.

[> ] I am sorry but I do not share your interpretation of above statement, it does not differentiate between control and non-control data. Infact it would be wrong to assume some data is non-control because ultimately  the whole point of transmitting data is to take some action based on it. Just because temperature readings are being sent out in the group that a thermostat uses to decide to switch on is same as sending a control command to the thermostat to switch on. So the above warning is appropriate in every case.

The whole thing about non-control multicast is that all nodes are somewhat equivalent in their threat models.  Each node gets all the traffic so compromise of the multicast key is no worse than compromise of any given node and vice versa.  Basically, getting access to the key is a side effect of getting access to the node's received traffic.  That's why using multicast symmetric keys for confidentiality is not a lose. (case 1)

[> ] Infact in our deployments we have sensors on every light source which makes every node a sensor and actuator. This is exactly why I am looking for a "case 1" security because of this side-effect that exists.

Conversely, in control multicast nodes are divided into control and actuator nodes.  In a good system, you'd need to compromise a control node to compromise the mesh control function, but in symmetric key control multicast compromise of any node is sufficient to compromise the mesh control function. (case 2)

Again, write this as non-control, confidentiality only symmetric key multicast, agree to have a "thou shalt not" use the multicast symmetric keys as authentication/authorization in the document and point to asymmetric systems for control functions and we can go forward. (case 3)  In fact, profile either GSAKMP or rfc 4046 along those lines.

Later, Mike

Regards

Sandeep

Later, Mike

-----Original Message-----

To: Rahman, Akbar; [email-masked]<mailto:[email-masked]>

dtls-iot mailing list

[email-masked]<mailto:[email-masked]>

---

From: peter van der Stok <[email-masked]>
Date: Mon, 22 Sep 2014 12:00:40 +0200

Hi Dorothy,

I agree with the conclusion that an impasse has been reached.
However, the secure multicast issue looks interesting.
Up till now only the lighting use case came up, but it may involve a lot 
of networks in the future, just like video transmission.
Also, a future use case may be in the field of fault tolerance where 
multiple sources send to multiple destinations.

Mathematically it seems to be clear why multicast increases the 
probability of unwanted decryption.
That seems to indicate that methods could be found to decrease this 
probability. It seems reasonable to me that such a subject is worked out 
in more detail. Would that be this wg?

Peter

Dorothy Gellert schreef op 2014-09-18 22:41:
> this Work item and move forward with the other 2 work items, the dtls
> profile and practical issues around the DTLS handshake.
>

---

From: Stefanie Gerdes <[email-masked]>
Date: Mon, 22 Sep 2014 18:42:35 +0200

Hi all,

sorry for picking this up again.

On 09/19/2014 07:45 PM, Michael StJohns wrote:

> stuff and not sending stuff.

I don't get why the opportunistic encryption case is different from the
multicast security case. In both cases people might not know that they
have less security than they think and thus might send data they would
not send otherwise.

Is it because in the OS case it is less likely that people are sending
data they wouldn't send without encryption? Or because the damage in the
multicast security case could be more severe?

Steffi

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Sep 2014 13:46:46 -0400

> have less security than they think and thus might send data they would

A good portion of existing OE is applied by a third party (e.g. at a 
gateway or router or even an MTA), and the sender is completely 
oblivious to whether or not it exists.  In that specific case, the 
analysis is "if I add confidentiality, does that make the situation 
worse?" by the third party.

The primary has already decided to send it - has probably not even 
considered whether or not it might be intercepted. The IT or network 
operator is just trying to improve things.

I don't necessarily like this (OE) model, because it can give a false 
sense of security, but the intent is to provide confidentiality, and not 
authenticity or authorization.

> multicast security case could be more severe?

There are basically a number of different multicast security axes - one 
is symmetric vs asymmetric cryptography, and another is sender identity 
important vs identity not-important.  In the "controls" case of 
multicast - where sending a multicast packet results in a change in the 
physical world in multiple places (e.g. doors open, lights go on, fans 
stop, electricity goes off), this is always an "identity important" 
case.  You only want to open a door if you're told to do so by someone 
authorized to have the door open.

Using symmetric key multicast keys as your credentials for that means 
that you can never be sure of the identity of the sender.  You know only 
that whoever sent the multicast packet had a copy of the multicast key.  
So while you might have thought that only the control station 
(lightswitch, access control panel, utility panel) was turning things on 
and off, in reality it could be anyone including someone who hacked your 
simple lightbulb that shared keys with your door locks.

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.

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Mon, 22 Sep 2014 20:08:12 +0000

From: Michael StJohns<mailto:[email-masked]>
Sent: ‎Monday‎, ‎September‎ ‎22‎, ‎2014 ‎7‎:‎46‎ ‎PM

Traditionally this would be true, but there are also other deployments where all devices in the group are both senders and receivers. As I mentioned Lighting is going in that direction since integrating sensors is cheap. Another example could be having all emergency doors open when a single emergency door is opened. In such “control” scenarios, it does not matter if it is symmetric or asymmetric crypto since there is no “asymmetry” in devices.

Why would you put the door locks in the same group as lights, what kind of synchronized behavior are you trying to achieve apart from an academic exercise at bad deployment practice.

---

From: Michael StJohns <[email-masked]>
Date: Mon, 22 Sep 2014 16:43:00 -0400

On 9/22/2014 4:08 PM, Kumar, Sandeep wrote:
>
> Why would you put the door locks in the same group as lights, what 
> kind of synchronized behavior are you trying to achieve apart from an 
> academic exercise at bad deployment practice.

Because people are cheap and using the same actuator for both a door and 
a door light is one of the ways to save money.  Or because someone 
thinks this is a wonderful replacement for X10 and doesn't read the 
warning labels. Or because someone wrote a controller that automatically 
takes charge of all the devices it sees and isn't smart enough to 
realize they all need different keys (and everyone goes along with the 
approach because its *easy* and doesn't require a lot of customer support).

You aren't writing an application protocol that applies to a very 
constrained usage domain, you're writing a L4 protocol that could 
conceivably end up anywhere for any purpose that "multicast control" is 
an interesting buzzword.  Pretending that there are sufficient 
credentials derived from this L4 protocol exchange to authenticate 
control actions is not universally correct, nor is it correct on most of 
the restricted domains we've talked about.

E.g. multicast control of street lights; multicast control of traffic 
lights; multicast control of self serve beer distribution systems (e.g. 
open bar at a party from 5-7); multicast control of power distribution 
automation systems; multicast control of a car charger (basically demand 
management); multicast control of a prison lock and key system;  
multicast control of a lock and key system for a school (or other 
institutional organizations);

With the possible exception of your specific scenario (lights in a 
residence), every other multicast control symmetric key system scenario 
scares me due to the potential for hacking and abuse and possible risk 
of life or limb.  Given that we haven't figured out how to constrain 
your protocol to your scenario, It seems to me that the better choice is 
to prevent the release of the protocol into the wild.

Mike

---

From: Ludwig Seitz <[email-masked]>
Date: Tue, 23 Sep 2014 09:07:07 +0200

On 09/22/2014 07:46 PM, Michael StJohns wrote:
....
> 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

---

From: Stefanie Gerdes <[email-masked]>
Date: Tue, 23 Sep 2014 12:43:31 +0200

Hi Michael,

> operator is just trying to improve things.

So OE is only okay as long as a sender does not care about it or is not
sure if it is there? That seems difficult to assure.

> authorized to have the door open.

I don't think that authorization necessarily requires a unique identity.
My (physical) door key has no identity attached to it. I only give it to
people that are allowed to enter my home. As long as the key is not lost
or stolen there is no problem with that. Companies may want to authorize
all their employees to open the door to the company building. In this
case, the authorization is based on their employment. The important
point for the door is if they are authorized to enter.

If the company hands out individual digital keys to its employees and an
attacker manages to steal only one of the keys, he is able to enter the
building with it. Unique identities cannot prevent that.

> simple lightbulb that shared keys with your door locks.

If I use a key for authenticating a sender, the receiver always only
knows that the sender has this key. There is no difference between
symmetric and asymmetric keys. If a key is stolen, the thief can use
this key to pretend to be someone else. No difference there, either.

The difference in your scenario is that there are different sets of
permissions bound to a single key. A control station might have
different permissions than a lightbulb. If the lightbulb has the same
permissions that means that it can act as a control station.

If an attacker steals a key that has too many permissions bound to it,
it can do more harm with it. That is again true for both symmetric and
asymmetric keys.

So if I understand your problem right you are suggesting that device
owners will have more difficulties to do authorization right when they
are using symmetric keys.

It might in theory be easier for a device owner to bind the right
permissions to a key that strictly belongs to an identified device. But
what does identity mean for a constrained device? An ID is not that
meaningful for authorization. The type of the device might be
meaningful, e.g. only switches must be allowed to access lightbulbs. I
wonder if it is less likely in this scenario that a device owner will
give all his devices the same permissions.

I learn from this that access permissions must be granted using the
need-to-know principle (each device must only have the permissions it
needs to fulfill its tasks) to mitigate the risk from a compromised
device. Whether or not it is more likely that an owner is unable to do
authorization right for symmetric or asymmetric scenarios I am not so sure.

Steffi

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 23 Sep 2014 11:08:43 +0000

I think there is more to it
A) only confidentiality
B) Integrity
        B.1) All devices are equal in the group (all members are senders and receivers)
        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.

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

> Sent: Tuesday, September 23, 2014 9:07 AM
> To: [email-masked]
> > 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
> A.) A protocol for multicast confidentiality in CoRE (with or without DTLS, I
> don't care)
>
> Where this work would be done is another question, B. seems like a task for
> ACE.
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2014 12:26:43 -0400

> sure if it is there? That seems difficult to assure.

Wow.  How did you get there?

The characteristic of OE is that the traffic is going to be sent 
regardless of any protections.  The sender may flip a bit, his system 
may be configured to flip a bit or a border box may be configured to 
flip a bit - said bit causing OE to happen.

Think about sending a letter - some end up in locked mailboxes at the 
recipients apartment, others are thrust into mailboxes that abut a 
street.  The sender generally has no idea of the at rest protections 
that will be applied to the letter he's sending, but he sends it 
anyways.  Think about how your cell phone conversation is encrypted 
between your cell and the cell tower, but not end to end. Most people 
making calls don't actually understand that their calls are unprotected 
on the hard wire.

There are a lot of similar analogies.  It's not that OE is OK if the 
sender doesn't care, its that OE MAY improve one tiny little piece of 
the security and the applying it or not does not generally change the 
equation with respect to whether the transmission happens or not.

> point for the door is if they are authorized to enter.

This is where people get confused about authorization and 
authentication.  In digital security terms, the person is using your 
authentication and authorization as a proxy.  Also, it's trivially easy 
to replicate a physical key, so the authorization and authentication 
aspect breaks down quickly.  For example, I have a key, I get fired, I 
tell them I lost the key, but there are 100s of them out there so they 
don't rekey.

The physical world is not an exact analog for the digital world. A 
better analog is a company that's replaced the keyed door locks with 
those that respond to swipe or RFID cards.  The cards are unique and the 
authorization to enter the building is tied to the card.  The employment 
status is irrelevant to the system (e.g. contractor, building 
maintenance staff, caterers etc), but may be relevant to the person 
managing the system (when adds/deletes are done).
> building with it. Unique identities cannot prevent that.
Nope.  But the revocation of the unique digital identity is a hell of a 
lot easier than revoking a single key used by 100s.  Also the guy losing 
the key is going to report it quickly - if for no other reason that to 
limit his liability.  Lose a common key, physical or digital and there's 
no incentive to report how you screwed up.

> this key to pretend to be someone else. No difference there, either.

In two party symmetric systems (not N party), the guarantee is "only two 
people share this key, I'm one of them and A is the other.  I didn't 
send it, so A must have, or he was hacked".

In a control model in a two party symmetric system where the key is used 
to have A order B to do something, then breaking in to A or breaking in 
to B is no worse than stealing the key.  In an N party system where A is 
the controller and B-F are actuators, then breaking in to F allows you 
to order B-E around even though F wasn't designated as a controlling node.

In an asymmetric system, I have to break into one specific device - A - 
to use the private key.  Breaking into F does not give me the 
credentials to control B-E.

> are using symmetric keys.

No, I'm actually not.  This is crypto 101.  The guidelines for symmetric 
keys is that you share them between at most two entities. For asymmetric 
keys, the private key is never shared.   If you follow these guidelines, 
you have a pretty good idea of who "signed" a control message.  If you 
don't, then you're screwed and it has nothing at all to do with whether 
or not your controller remains secure.

I'm specifically saying that using multi-party symmetric keys to do 
control actions is insecure out of the box.  For absence of doubt, that 
applies whether we're talking multicast or using the same key for 
multiple unicast messages.

To continue, in general, using multi-party symmetric keys for 
confidentiality is ALSO a bad idea.  For multicast, its only slightly 
less of a bad idea because the compromise of the node with the multicast 
key, gets you the data being sent with the multicast key anyways.  
Multiparty symmetric keys provide no authentication of sent data.  2 
party symmetric keys provide authentication that the other holder of the 
key - to the extent he or I haven't been compromised - sent the data 
that I received under that key.

> authorization right for symmetric or asymmetric scenarios I am not so sure.

You need to go back an review role based authorization vs identity based 
authentication.  They are different.  I can have many many 
lightswitches, but the one at the top of my stairs is unique.  And 
should only be controlling the lights on my top landing.  I might have a 
lightswitch with a role of "master controller" that can turn on and off 
all the lights in my house, and tie the "master controller" 
authorization to that privilege in each light switch, but that's 
different from a) the identity of the light switch, and b) the 
assignment of the role of master controller to that lightswitch.

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2014 12:49:11 -0400

On 9/23/2014 3:07 AM, Ludwig Seitz wrote:
> Where this work would be done is another question, B. seems like a 
> task for ACE.
>

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/

---

From: Dorothy Gellert <[email-masked]>
Date: Tue, 23 Sep 2014 10:22:56 -0700

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 <[email-masked]> wrote:

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

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2014 13:53:15 -0400

On 9/23/2014 1:22 PM, Dorothy Gellert wrote:
> 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”.

Yup.  But to do that, the rest of the document has to conform.  E.g. NO 
using multicast keys for control.  That means substantial changes to the 
document as is.

And that's if and only if there's another scenario or two where 
confidentiality makes sense - not sure there is.

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

I'm still on the "withdraw the document, delete multicast from our 
charter" position.  The above is if and only if....

Mike

>
> Thanks,
> Dorothy
>
>
>
>
>
>
>
> On Sep 23, 2014, at 9:49 AM, Michael StJohns <[email-masked] 
>>>> than
>> 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 
>> 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 -
>>
>> 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/
>>
>>

---

From: Dorothy Gellert <[email-masked]>
Date: Tue, 23 Sep 2014 11:41:50 -0700

Hi Mike,   

I’ve considered your position in the consensus call.. no need to restate it.    Thanks for volunteering  to draft a security considerations section. 

For those who have not yet voiced their options, please weigh in on the way forward on multicast security:  Protocol for multicast confidentiality in CoRE.

Regards,
Dorothy

On Sep 23, 2014, at 10:53 AM, Michael StJohns <[email-masked]> wrote:

> Yup.  But to do that, the rest of the document has to conform.  E.g. NO using multicast keys for control.  That means substantial changes to the document as is.
> 
> And that's if and only if there's another scenario or two where confidentiality makes sense - not sure there is.
> 
> 
>> 
> I'm still on the "withdraw the document, delete multicast from our charter" position.  The above is if and only if....
> 
> Mike
> 
>> 
>> Thanks,
>> Dorothy
>> 
>> 
>> 
>> 
>> 
>> 
>>

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 23 Sep 2014 18:42:23 +0000

We do have some multicast discovery messaging which needs confidentiality, I will need to check internally how much we can share.

May this is being ignored for some reason but I would prefer that it is also extended with all the " pretty restrictive, pretty blunt security considerations section” to control in groups where all members are equal, each member can control all others in the group to perform the same action.
Sandeep

From: Michael StJohns<mailto:[email-masked]>
Sent: ‎Tuesday‎, ‎September‎ ‎23‎, ‎2014 ‎7‎:‎53‎ ‎PM
To: Dorothy Gellert<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Mike

Thanks,
Dorothy

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

Aha!

/Ludwig

Later, Mike

ps -

---

From: Dorothy Gellert <[email-masked]>
Date: Tue, 23 Sep 2014 11:50:21 -0700

Thanks Sandeep.

I would be in favor of that extension.

BR-
Dorothy

Thanks for 
On Sep 23, 2014, at 11:42 AM, Kumar, Sandeep <[email-masked]> wrote:

> From: Michael StJohns
> To: Dorothy Gellert, [email-masked]
>

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2014 15:24:13 -0400

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

> I think there is more to it
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.

> 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 t…

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

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 23 Sep 2014 19:36:34 +0000

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:[email-masked]>
Sent: ‎Tuesday‎, ‎September‎ ‎23‎, ‎2014 ‎9‎:‎24‎ ‎PM
To: [email-masked]<mailto:[email-masked]>

Later, Mike

---

From: Michael StJohns <[email-masked]>
Date: Tue, 23 Sep 2014 16:03:16 -0400

On 9/23/2014 3:36 PM, Kumar, Sandeep wrote:
> 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.
>
>

Any other scenarios?  So far we're writing a general purpose protocol to 
control lamps in a home and for no other purpose.   What else would you 
use the "all nodes are equal" approach on?

What you've described isn't actually an all nodes are equal thing. What 
you've done is combined a controller with all the controlled as a 
packaging decision.  The light is still distinct in its actions from the 
controller, even if the controller is physically bundled with it.  A 
cheaper solution might actually to be to place two presence sensors (one 
at each door, above pet level) to control the 20 or 30 lights in a very 
large room.  There's no domain reason that a light needs to also be a 
controller except to make your argument and a lot of reasons (cost for 
example) not to.

A better model might be flocking drones. 
http://www.nature.com/news/autonomous-drones-flock-like-birds-1.14776 
There's no master/slave relationship, they do things by emergent 
behavior from common rules and data received locally and from their 
flock mates.

Later, Mike

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 23 Sep 2014 22:08:53 +0000

Sent from Windows Mail

From: Michael StJohns<mailto:[email-masked]>
Sent: ‎Tuesday‎, ‎September‎ ‎23‎, ‎2014 ‎10‎:‎03‎ ‎PM
To: [email-masked]<mailto:[email-masked]>, [email-masked]<mailto:[email-masked]>

Any other scenarios?  So far we're writing a general purpose protocol to control lamps in a home and for no other purpose.   What else would you use the "all nodes are equal" approach on?

I have heard about a similar use case for window sun-blinds in office buildings with integrated sensors which want to open/close together. Need to get more details from the original source. I am sure there are more such cases.

What you've described isn't actually an all nodes are equal thing.  What you've done is combined a controller with all the controlled as a packaging decision.  The light is still distinct in its actions from the controller, even if the controller is physically bundled with it.  A cheaper solution might actually to be to place two presence sensors (one at each door, above pet level) to control the 20 or 30 lights in a very large room.  There's no domain reason that a light needs to also be a controller except to make your argument and a lot of reasons (cost for example) not to.

You will be surprised how the economics of integrating an additional sensor into existing devices can offset the cost of an additional standalone device during the lifecycle of the whole system. Apart from economics there are other functional reasons that makes such a system more reliable.

A better model might be flocking drones.  http://www.nature.com/news/autonomous-drones-flock-like-birds-1.14776  There's no master/slave relationship, they do things by emergent behavior from common rules and data received locally and from their flock mates.

Good one!

Later, Mike

---

From: Ludwig Seitz <[email-masked]>
Date: Wed, 24 Sep 2014 12:36:39 +0200

> call, specifically, that we pursue A) Protocol for multicast

Yes I confirm my support for pursuing A)

/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

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 24 Sep 2014 16:20:25 +0000

Hi Dorothy,

Yes, I also support doing option A).

Best Regards,

Akbar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Dorothy Gellert
Sent: Tuesday, September 23, 2014 1:23 PM
To: [email-masked]
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".

Thanks,
Dorothy

/Ludwig

Later, Mike

ps -

---

From: Carsten Bormann <[email-masked]>
Date: Wed, 24 Sep 2014 18:41:23 +0200

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

That is certainly one element.
I continue to believe we need group authentication/integrity/replay protection as well.

Grüße, Carsten

---

From: Sye Loong Keoh <[email-masked]>
Date: Thu, 25 Sep 2014 02:12:43 +0000

Hi Dorothy,

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

Many thanks
Sye Loong

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

Hi All,

Thanks,
Dorothy

/Ludwig

Later, Mike

ps -

---

From: Robert Cragie <[email-masked]>
Date: Thu, 25 Sep 2014 07:14:31 +0100

Hi Dorothy,

I also support moving forward with option A.

Robert
On 23 Sep 2014 18:22, "Dorothy Gellert" <[email-masked]> wrote:

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