Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

[Kathleen Moriarty <[e-mail]>]

Hello,



On Tue, Jul 26, 2016 at 7:10 AM, Kumar, Sandeep <[e-mail]>
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:[e-mail]]
> *Sent:* Tuesday, July 26, 2016 3:00 AM
> *To:* Kumar, Sandeep; Stephen Farrell; Somaraju Abhinav; Michael StJohns;
> [e-mail]
>
> *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:[e-mail] <[e-mail]>] On Behalf
> Of Stephen Farrell
> Sent: Monday, July 25, 2016 9:26 PM
> To: Somaraju Abhinav; Michael StJohns; [e-mail]
> 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
>
> [e-mail]
>
> https://www.ietf.org/mailman/listinfo/ace
>
>
>
>
>
> --
>
> email: [e-mail] | Skype: rstruik
>
> cell: [phone] | US: [phone]
>
>
> _______________________________________________
> Ace mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/ace
>
>


-- 

Best regards,
Kathleen