Hello,
On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <[email protected]> wrote: > Hi Rene > > > > Makes more sense this way. Need to also add replay protection but that > should be just part of the hash. Will it make things better for user > experience? That depends on how big the pool of (good randomized) > pre-computed values can be created before they run out and causes a stuck > behavior. > If things can be made better, we should of course do that. However, there are risk tradeoffs that sometimes make sense. If it is not possible to precompute keys for speed, storage or some other reason, we need to figure that out and have it factored into a threat model. This should all be part of a security considerations section (whatever is decided). We are talking about cyber physical devices and controllers, in this case lightbulbs. Sure, lightbulbs are evolving, so it may make a difference if we are talking about lightbulbs that can turn on/off, dim, change colors, or ones that perform other functions (MIT Media Lab type stuff). It also matters if we are talking about use of lights within a controlled area and whether it is connected to other networks or not (IoT devices, Internet, protected network, etc.). No one is suggesting that the same key be used in multiple environments, but a single group key for one environment. There are always tradeoffs in security and that's okay. What is the bigger threat model? Lights turning on/off in large buildings could result in increased energy costs. Lights turning on/off could result in safety issues (they could be extreme). What measures would mitigate these (and maybe other risks)? Suggest dividing up large buildings into sets so that a single group key could be used in that set. Limit connections to other networks or have protective measures between them. Maybe someone in this space can help more to build out the threat model to help the WG with this decision. There are still some unanswered questions about the capabilities of hardware, are the alternate solutions to a group key feasible? Will blocking the use of a single group key prevent the ability to move forward with a standard? Thanks, Kathleen > > > Regards > > Sandeep > > > > > > > > *From:* Rene Struik [mailto:[email protected]] > *Sent:* Tuesday, July 26, 2016 3:00 AM > *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael StJohns; > [email protected] > > *Subject:* Re: [Ace] Adoption of Low Latency Group Communication Security > Work in ACE > > > > Hi Sandeep: > > Fair enough, but with, e.g., ECDSA, computation of the ephemeral key R:=kG > can be carried out independently of the remainder of the signature > computation (where one computes e:=h(m), and calculates s:=(1/k)(e-r*d)(mod > n) and subsequently outputs (r,s), where r is derived from R). So, if one > wishes to, one can pre-compute many ephemeral key pairs (k, kG) and use > those on demand {David Naccache, if I remember correctly, elaborated on > these types of "labor division" in a 1998 paper}. So, in the Philips > high-granularity luminary, the one simply hashes the state (still only a > few-bytes entry) and then combines e with r, d, k, to produce signature > component s -- a simple linear equation with two modular multiplies as cost. > > Let's make things better... > > Rene > > On 7/25/2016 5:34 PM, Kumar, Sandeep wrote: > > Because sometimes a lightswitch can have more than two states. > > [image: > http://images.philips.com/is/image/PhilipsConsumer/6916431PH-IMS-en_GB?wid=494&hei=435&$pnglarge$] > > The color dial on this switch (src: > http://www.philips.co.uk/c-p/6916431PH/livingcolors-remote-control) can > set the color of lights one chooses. That would be quite some > precomputations. > > > > Sandeep > > > > > > -----Original Message----- > From: Ace [mailto:[email protected] <[email protected]>] On Behalf > Of Stephen Farrell > Sent: Monday, July 25, 2016 9:26 PM > To: Somaraju Abhinav; Michael StJohns; [email protected] > Subject: Re: [Ace] Adoption of Low Latency Group Communication Security > Work in ACE > > > > > > > > On 25/07/16 17:59, Somaraju Abhinav wrote: > > > we essentially have 50-100 ms for the signing+verification process and > > > I do not know of a solution that does this > > > > Just a clarifying question: why can't the signing possibly be done > asynchronously? E.g. the private key holder could sign a value that will > only be sent later - as long as it has one of those ready to emit whenever > needed one can ignore the signing time. That can have power consumption > consequences but I'd guess that's ok for a lightswitch. > > > > If signing can be done ahead of time, then only verification time has to > be considered. > > > > S. > > > > > > > ------------------------------ > > 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. > > > > _______________________________________________ > > Ace mailing list > > [email protected] > > https://www.ietf.org/mailman/listinfo/ace > > > > > > -- > > email: [email protected] | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > > _______________________________________________ > Ace mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/ace > > -- Best regards, Kathleen
_______________________________________________ Ace mailing list [email protected] https://www.ietf.org/mailman/listinfo/ace
