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. >> >> 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. > 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. > >> 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. 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
