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 <d.stu...@att.net> 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 <ace-boun...@ietf.org> on behalf of Kathleen Moriarty > <kathleen.moriarty.i...@gmail.com> > Date: Saturday, December 24, 2016 at 8:19 AM > To: Michael StJohns <mstjo...@comcast.net> > Cc: Eliot Lear <l...@cisco.com>, "ace@ietf.org" <ace@ietf.org> > Subject: Re: [Ace] where are we with draft-somarju-ace-multicast? > > 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 <mstjo...@comcast.net> >> wrote: >>> On 12/23/2016 3:24 AM, Eliot Lear wrote: >>> >>>> On 12/22/16 11:36 PM, Michael StJohns wrote: >>>> >>>>> On 12/22/2016 3:42 AM, Eliot Lear wrote: >>>>> 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. > > Thank you for your efforts, Eliot! >>>>> >>>>> On the one hand, we have a draft that there seems to be unanimous >>>>> 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. >>>> >>> 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. >> >> >>> >>>> 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. >>> 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. >> >> 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? > > 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 >>>>> 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. >>>> 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? >>> The answer should be as it always was: make things better. >> In what world is "make things better" a security requirement? >> >>> 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. >> >> 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. >> >> >>> >>>> 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. >> >> 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 >>> 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. >> >> 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. > > I thought we were working on multiple solutions and moving on? > > Happy holidays! > Kathleen > >> >> >> Mike >> >> >> >>> >>> Eliot >>> >> >> _______________________________________________ >> Ace mailing list >> Ace@ietf.org >> https://www.ietf.org/mailman/listinfo/ace > > > > -- > > Best regards, > Kathleen > _______________________________________________ Ace mailing list Ace@ietf.org > https://www.ietf.org/mailman/listinfo/ace
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace
