Subject: [Ace] where are we with draft-somarju-ace-multicast?

From: Eliot Lear <[email-masked]>
Date: Thu, 22 Dec 2016 09:42:48 +0100

Hi,

This working group has been in a state of indecision about this draft
for quite some time and I would like to gain some clarity on the matter.

On the one hand, we have a draft that there seems to be unanimous
agreement would be useful to the lighting people.  On the other hand, we
have some concern that the draft might be misapplied to environments
where PSK/symmetric keys should not be employed. 

As Hannes wrote, security is not a black and white matter.  We need to
acknowledge that fact.  This, to me, seems to boil down to an
applicability statement. 

On the matter of status, it is not appropriate to release this as an
experiment.  People want to code, release that code and see their
customers use that code.  This is precisely what a proposed standard is for.

I would like to see this draft adopted by the working group, an
appropriate applicability statement added, and see it shipped.

Eliot

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 22 Dec 2016 10:16:52 +0100

> appropriate applicability statement added, and see it shipped.

+1

(Everything has been said already that needs to be said about the issue.)

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Thu, 22 Dec 2016 17:36:12 -0500

On 12/22/2016 3:42 AM, Eliot Lear wrote:
> agreement would be useful to the lighting people.
Actually, we have a draft that the lighting people unanimously agree 
that would be useful to the lighting people.  Not quite the same thing.

And, as I've said before, if this is ONLY applicable to the lighting 
people then they should go off and write an Informational "Here's how we 
do it" document and not try for an internet standard.

> On the other hand, we

I don't know why people think I'm just going to let things pass without 
trying to inject some rigor.

My last question:  What is the security requirement for an ACE Group 
comm protocol?

My current minimum bid:  Compromise of a single device shall not result 
in the attacker gaining privileges over the group greater than those 
nominally granted to the device being attacked.  or less nuanced:  
Compromise of a single device shall not result in the compromise of the 
entire group.

I asked the above question a month ago in response to Hannes' email and 
received no answer.  None.

As far as I can glean from the discussion (this one and the 2 year one 
in DTLS), the current answer from the lighting folk to "What is the 
security requirement" is "we don't really care as long it is weak enough 
that we don't have to pay for hardware or endure latency for validation 
so we can use this fundamentally insecure symmetric key group system".  
I apologize if that's unfair, but I literally haven't been able to find 
ANY indication that there's any consideration in selecting the 
"security" solution than this.

And as far as I can tell, that means that their security requirement is 
the empty set - which is sort of an appropriate name for security theater.

Can ANYONE provide me with a parseable and non-empty security 
requirement for symmetric key group communications?

> customers use that code.  This is precisely what a proposed standard is for.

For an "ACE Group comm" protocol, it has to be generally applicable to 
the ACE space, and not just this this tiny hardware and cost constrained 
corner. An Informational RFC by the lighting folk provided as whole 
cloth is the appropriate approach - not an internet standard in any way 
shape or form.

> appropriate applicability statement added, and see it shipped.

I would like a security group to actually produce secure protocols.   
I'm not even sure this approach is applicable to the lighting scenario 
in any meaningful way.

Mike

>
> Eliot
>
>
>
>
> _______________________________________________
> Ace mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ace

---

From: Eliot Lear <[email-masked]>
Date: Fri, 23 Dec 2016 09:24:27 +0100

> that would be useful to the lighting people.  Not quite the same thing.

No, even you have previously conceded that this use case is fine.

> people then they should go off and write an Informational "Here's how
> we do it" document and not try for an internet standard.

It's not.  Lighting is not the only highly constrained case where low
power budget and low latency requirements will make public key
operations expensive.  It just happens to be leading the path.

> I don't know why people think I'm just going to let things pass
> without trying to inject some rigor.
>

The answer should be as it always was: make things better.  The current
alternative is nothing, which is what happens today, and well beyond
lighting.  The current draft provides for use of asymmetric keying for
group admission.  Beyond that, the choices are pretty stark: perform an
symmetric operation on every transaction or use a group key.

>
> My current minimum bid:  Compromise of a single device shall not
> result in the attacker gaining privileges over the group greater than
> those nominally granted to the device being attacked.  or less
> nuanced:  Compromise of a single device shall not result in the
> compromise of the entire group. 

And here's mine:

The group must be treated as a single device, for purpose of compromise,
barring additional measures being taken at other layers.  The advantage
of this over status quo is that today admission is open, and the threat
surface is therefore unconstrained.  With this approach the threat
surface is reduced to other infected group members.

Eliot

---

From: Michael StJohns <[email-masked]>
Date: Fri, 23 Dec 2016 12:41:57 -0500

> No, even you have previously conceded that this use case is fine.

Really?  Where and when?    What I said was that I didn't believe this 
draft was even conditionally secure for control systems, and that while 
I thought it was a bad idea, I was fine with the lighting folk going off 
and publishing it as informational for their own internal use.

> operations expensive.  It just happens to be leading the path.

Can you think of even one other case where low cost (not low power - 
seriously, it's a light bulb and it's plugged in) and low latency so 
constrain the problem that nothing but a symmetric solution will work?  
I can't.  And I can't remember even a suggestion that there was another 
one.  Remember that the latency issues here are related to human 
perception and to nothing else.

So use case other than lighting is?

> The answer should be as it always was: make things better.
In what world is "make things better" a security requirement?

>   The current

I'm not sure if you meant "perform an asymmetric operation..." or you 
were stating a false dilemma by limiting the choices.  The asymmetric 
keying for group admission is nothing new, and probably doesn't 
materially affect the security of the protocol.

If you've got a content distribution system, then the use of group 
symmetric keys is a valid option - mainly because the compromise of an 
end device is no worse than the compromise of the group key as you get 
access to the content by breaking into an end system.  But that's not 
what this is.

If you've got a one-to-many control system, then the use of group 
symmetric keys is not an option, because the compromise of an end or 
actuator device gives you the access to control other end or actuator 
devices.    There are caveats and mitigations here dealing with key 
protection and secure elements (which cost money or power), but the 
general case is as stated.

ACE should be working on the general case of the security of a group 
control system, and it's pretty clear that - for the general case - only 
an asymmetric approach for "signing" the control messages has the 
necessary security properties.

> barring additional measures being taken at other layers.

Um. No.  This requirement is valid if and only if each and every device 
in the group has exactly the same privileges with respect to the group.  
If I compromise a light switch, I get its privileges to turn on and off 
the group.  If I compromise a light bulb, why should I get privileges to 
turn on and off the group?

I actually described the above as a possibility for say a 
collection/flock of drones way back in DICE.  But even then I would 
suggest that hardware protection of the symmetric key would be necessary 
for meaningful security guarantees for any group larger than about 4 or 8.

>   The advantage

I believe that your analysis is flawed.  Basically, the cost to attack 
any of the entities in the lighting case approaches zero, especially if 
you can physically access one.  The probability of success of attacking 
such entities approaches unity.  The security guarantees for this are 
therefore roughly equivalent to  no security at all and may be worse 
than no security at all because the general public will not inquire as 
to what "secure" means for any given case. Or put another way, this is 
no better than security by obscurity.

There are any number of products that tout security in their ads or 
specifications, but when you get under the covers you recoil in horror 
at finding just how trivial it would be to penetrate.

I expect going forward that any device or item can be broken into with 
some level of effort given physical or network access.  What I don't 
want to have happen - due to our poor choices - is making the Work 
Factor of the group (to break in) identical to the Work Factor of 
breaking into a single device and that's what this draft is proposing to 
institutionalize in the protocol.  We can do better and we should.

Mike

---

From: Kathleen Moriarty <[email-masked]>
Date: Sat, 24 Dec 2016 11:19:57 -0500

We continue to go in circles on this despite efforts to mitigate or warn of
risks and agreement to put forth an asymmetric key solution at the same
time.  This continued DoS on this topic is serving no purpose but to delay
vendors or send them elsewhere when they are here in ACE looking for
assistance to standardize a solution (or solutions).

I thought we had some agreement to go forward with both solutions.  I see
Mike is requesting that this be informational and that's one possible
route, but I'm not convinced.  I do think we should go forward adopting the
solutions, working on them and figuring out the status and constraining
language in parallel. inline,

>>>> for quite some time and I would like to gain some clarity on the matter.
Thank you for your efforts, Eliot!

> draft was even conditionally secure for control systems, and that while I
> thought it was a bad idea, I was fine with the lighting folk going off and
> publishing it as informational for their own internal use.
>
>
>
> constrain the problem that nothing but a symmetric solution will work?  I
> can't.  And I can't remember even a suggestion that there was another one.
> Remember that the latency issues here are related to human perception and
> to nothing else.
>

I don't see why it matters.  If we have lighting vendors who want to work
with us in ACE, why can't we devise a couple of solutions specific to their
space?  These questions are only relevant to the constraining language that
gets added to the draft(s).

> I'm not sure if you meant "perform an asymmetric operation..." or you were
> stating a false dilemma by limiting the choices.  The asymmetric keying for
> group admission is nothing new, and probably doesn't materially affect the
> security of the protocol.
>
> symmetric keys is a valid option - mainly because the compromise of an end
> device is no worse than the compromise of the group key as you get access
> to the content by breaking into an end system.  But that's not what this is.
>
> protection and secure elements (which cost money or power), but the general
> case is as stated.
>
> control system, and it's pretty clear that - for the general case - only an
> asymmetric approach for "signing" the control messages has the necessary
> security properties.
>
>
>
> Um. No.  This requirement is valid if and only if each and every device in
> the group has exactly the same privileges with respect to the group.  If I
> compromise a light switch, I get its privileges to turn on and off the
> group.  If I compromise a light bulb, why should I get privileges to turn
> on and off the group?
>

Fine, let's constrain it as such and move on.  There are use cases for
lighting that do not require high security.  If you overbuild, it will not
get used.  We just need to provide an alternate more secure solution
detailing when it is to be used at the same time a symmetric key solution
is published (standards or informational track TBD).

>
> I actually described the above as a possibility for say a collection/flock
> of drones way back in DICE.  But even then I would suggest that hardware
> protection of the symmetric key would be necessary for meaningful security
> guarantees for any group larger than about 4 or 8.
>
>
>
>   The advantage
> I believe that your analysis is flawed.  Basically, the cost to attack any
> of the entities in the lighting case approaches zero, especially if you can
> physically access one.  The probability of success of attacking such
> entities approaches unity.  The security guarantees for this are therefore
> roughly equivalent to  no security at all and may be worse than no security
> at all because the general public will not inquire as to what "secure"
> means for any given case. Or put another way, this is no better than
> security by obscurity.
>

In some scenarios, lower security is all that is needed.  If a zone in an
office building turns off when an employee leaves the room, this zone (a
single device) is compromised, worse case scenario might be a high bill for
the month.  Settings like hospitals would not be appropriate for this
solution and that should be called out explicitly.  The risk decision is
always made by the implementor, we just need to give them the information
needed to make appropriate decisions.

> specifications, but when you get under the covers you recoil in horror at
> finding just how trivial it would be to penetrate.
>

Sure, but let's figure out if there is a way to do this and list
appropriate protections for the "device" or zone, etc. where a shared key
is in use.

> some level of effort given physical or network access.  What I don't want
> to have happen - due to our poor choices - is making the Work Factor of the
> group (to break in) identical to the Work Factor of breaking into a single
> device and that's what this draft is proposing to institutionalize in the
> protocol.  We can do better and we should.

I thought we were working on multiple solutions and moving on?

Happy holidays!
Kathleen

-- 

Best regards,
Kathleen

---

From: Don Sturek <[email-masked]>
Date: Sat, 24 Dec 2016 09:12:26 -0800

Hi Kathleen,

Having worked on these lighting solutions and knowing the security
limitations, I think the Informational RFC is best.   Creating a standard
(even with ample warnings and proposed limitations) will only end up in
disappointment and embarrassment when someone finds a more creative security
break with these solutions .

Happy holidays to all!

Don Sturek

From:  Ace <[email-masked]> on behalf of Kathleen Moriarty
<[email-masked]>
Date:  Saturday, December 24, 2016 at 8:19 AM
To:  Michael StJohns <[email-masked]>
Cc:  Eliot Lear <[email-masked]>, "[email-masked]" <[email-masked]>
Subject:  Re: [Ace] where are we with draft-somarju-ace-multicast?

I thought we had some agreement to go forward with both solutions.  I see
Mike is requesting that this be informational and that's one possible route,
but I'm not convinced.  I do think we should go forward adopting the
solutions, working on them and figuring out the status and constraining
language in parallel. inline,

> Really?  Where and when?    What I said was that I didn't believe this draft
> was even conditionally secure for control systems, and that while I thought it
> was a bad idea, I was fine with the lighting folk going off and publishing it
> as informational for their own internal use.
> 
> 
>> 
> seriously, it's a light bulb and it's plugged in) and low latency so constrain
> the problem that nothing but a symmetric solution will work?  I can't.  And I
> can't remember even a suggestion that there was another one.  Remember that
> the latency issues here are related to human perception and to nothing else.
> 

> If you've got a content distribution system, then the use of group symmetric
> keys is a valid option - mainly because the compromise of an end device is no
> worse than the compromise of the group key as you get access to the content by
> breaking into an end system.  But that's not what this is.
> 
> If you've got a one-to-many control system, then the use of group symmetric
> keys is not an option, because the compromise of an end or actuator device
> gives you the access to control other end or actuator devices.    There are
> caveats and mitigations here dealing with key protection and secure elements
> (which cost money or power), but the general case is as stated.
> 
> ACE should be working on the general case of the security of a group control
> system, and it's pretty clear that - for the general case - only an asymmetric
> approach for "signing" the control messages has the necessary security
> properties.
> 
> 
>> 
> Um. No.  This requirement is valid if and only if each and every device in the
> group has exactly the same privileges with respect to the group.  If I
> compromise a light switch, I get its privileges to turn on and off the group.
> If I compromise a light bulb, why should I get privileges to turn on and off
> the group?

Fine, let's constrain it as such and move on.  There are use cases for
lighting that do not require high security.  If you overbuild, it will not
get used.  We just need to provide an alternate more secure solution
detailing when it is to be used at the same time a symmetric key solution is
published (standards or informational track TBD).
 
> 
> I actually described the above as a possibility for say a collection/flock of
> drones way back in DICE.  But even then I would suggest that hardware
> I believe that your analysis is flawed.  Basically, the cost to attack any of
> the entities in the lighting case approaches zero, especially if you can
> physically access one.  The probability of success of attacking such entities
> approaches unity.  The security guarantees for this are therefore roughly
> equivalent to  no security at all and may be worse than no security at all
> because the general public will not inquire as to what "secure" means for any
> given case. Or put another way, this is no better than security by obscurity.

> finding just how trivial it would be to penetrate.

Sure, but let's figure out if there is a way to do this and list appropriate
protections for the "device" or zone, etc. where a shared key is in use.
 
> 
> I expect going forward that any device or item can be broken into with some
> level of effort given physical or network access.  What I don't want to have
> happen - due to our poor choices - is making the Work Factor of the group (to
> break in) identical to the Work Factor of breaking into a single device and
> that's what this draft is proposing to institutionalize in the protocol.  We
> can do better and we should.

Happy holidays!
Kathleen

-- 

Best regards,
Kathleen
_______________________________________________ Ace mailing list
[email-masked] https://www.ietf.org/mailman/listinfo/ace

---

From: [email-masked]
Date: Sat, 24 Dec 2016 13:24:48 -0500

Thanks, Don.

Your input is helpful.  I'd just like to see this discussion settled and to see progress.  The chairs are managing at this point.  If justified, either can work with agreement.  My point was more to get things moving.

Thank you,
Kathleen 

Please excuse typos, sent from handheld device 

> On Dec 24, 2016, at 12:12 PM, Don Sturek <[email-masked]> wrote:
> 
> Hi Kathleen,
> 
> Having worked on these lighting solutions and knowing the security limitations, I think the Informational RFC is best.   Creating a standard (even with ample warnings and proposed limitations) will only end up in disappointment and embarrassment when someone finds a more creative security break with these solutions .
> 
> Happy holidays to all!
> 
> Don Sturek
> 
> 
> 
> From: Ace <[email-masked]> on behalf of Kathleen Moriarty <[email-masked]>
> We continue to go in circles on this despite efforts to mitigate or warn of risks and agreement to put forth an asymmetric key solution at the same time.  This continued DoS on this topic is serving no purpose but to delay vendors or send them elsewhere when they are here in ACE looking for assistance to standardize a solution (or solutions). 
> 
> I thought we had some agreement to go forward with both solutions.  I see Mike is requesting that this be informational and that's one possible route, but I'm not convinced.  I do think we should go forward adopting the solutions, working on them and figuring out the status and constraining language in parallel. inline,
> 
>> On Fri, Dec 23, 2016 at 12:41 PM, Michael StJohns <[email-masked]> wrote:
>> Really?  Where and when?    What I said was that I didn't believe this draft was even conditionally secure for control systems, and that while I thought it was a bad idea, I was fine with the lighting folk going off and publishing it as informational for their own internal use.
>> 
>> 
>>> 
>> Can you think of even one other case where low cost (not low power - seriously, it's a light bulb and it's plugged in) and low latency so constrain the problem that nothing but a symmetric solution will work?  I can't.  And I can't remember even a suggestion that there was another one.  Remember that the latency issues here are related to human perception and to nothing else.
>> 
> I don't see why it matters.  If we have lighting vendors who want to work with us in ACE, why can't we devise a couple of solutions specific to their space?  These questions are only relevant to the constraining language that gets added to the draft(s). 
> 
>> 
>> 
>> 
>>> 
>>>>> On the other hand, we
>> I'm not sure if you meant "perform an asymmetric operation..." or you were stating a false dilemma by limiting the choices.  The asymmetric keying for group admission is nothing new, and probably doesn't materially affect the security of the protocol.
>> 
>> If you've got a content distribution system, then the use of group symmetric keys is a valid option - mainly because the compromise of an end device is no worse than the compromise of the group key as you get access to the content by breaking into an end system.  But that's not what this is.
>> 
>> If you've got a one-to-many control system, then the use of group symmetric keys is not an option, because the compromise of an end or actuator device gives you the access to control other end or actuator devices.    There are caveats and mitigations here dealing with key protection and secure elements (which cost money or power), but the general case is as stated.
>> 
>> ACE should be working on the general case of the security of a group control system, and it's pretty clear that - for the general case - only an asymmetric approach for "signing" the control messages has the necessary security properties.
>> 
>> 
>>> 
>> Um. No.  This requirement is valid if and only if each and every device in the group has exactly the same privileges with respect to the group.  If I compromise a light switch, I get its privileges to turn on and off the group.  If I compromise a light bulb, why should I get privileges to turn on and off the group?
> 
> Fine, let's constrain it as such and move on.  There are use cases for lighting that do not require high security.  If you overbuild, it will not get used.  We just need to provide an alternate more secure solution detailing when it is to be used at the same time a symmetric key solution is published (standards or informational track TBD).
>  
>> 
>> I actually described the above as a possibility for say a collection/flock of drones way back in DICE.  But even then I would suggest that hardware protection of the symmetric key would be necessary for meaningful security guarantees for any group larger than about 4 or 8.
>> 
>> 
>> 
>>>   The advantage
>> I believe that your analysis is flawed.  Basically, the cost to attack any of the entities in the lighting case approaches zero, especially if you can physically access one.  The probability of success of attacking such entities approaches unity.  The security guarantees for this are therefore roughly equivalent to  no security at all and may be worse than no security at all because the general public will not inquire as to what "secure" means for any given case. Or put another way, this is no better than security by obscurity.
> 
> In some scenarios, lower security is all that is needed.  If a zone in an office building turns off when an employee leaves the room, this zone (a single device) is compromised, worse case scenario might be a high bill for the month.  Settings like hospitals would not be appropriate for this solution and that should be called out explicitly.  The risk decision is always made by the implementor, we just need to give them the information needed to make appropriate decisions.  
>> 
>> There are any number of products that tout security in their ads or specifications, but when you get under the covers you recoil in horror at finding just how trivial it would be to penetrate.
> 
> Sure, but let's figure out if there is a way to do this and list appropriate protections for the "device" or zone, etc. where a shared key is in use.
>  
>> 
>> I expect going forward that any device or item can be broken into with some level of effort given physical or network access.  What I don't want to have happen - due to our poor choices - is making the Work Factor of the group (to break in) identical to the Work Factor of breaking into a single device and that's what this draft is proposing to institutionalize in the protocol.  We can do better and we should.
> 
> _______________________________________________ Ace mailing list [email-masked] https://www.ietf.org/mailman/listinfo/ace