On Thu, Nov 17, 2016 at 10:56 PM, Tirumaleswar Reddy (tireddy) < tire...@cisco.com> wrote:
> Kathleen, > > > > I will put up a proposal before the Chicago meeting. > Thank you. > > > -Tiru > > > > *From:* Ace [mailto:ace-boun...@ietf.org] *On Behalf Of * > kathleen.moriarty.i...@gmail.com > *Sent:* Friday, November 18, 2016 5:30 AM > *To:* Rene Struik <rstruik....@gmail.com> > *Cc:* Michael StJohns <mstjo...@comcast.net>; ace@ietf.org > *Subject:* Re: [Ace] Summary of ACE Group Communication Security > Discussion > > > > Is anyone willing to work on a draft to be ready in advance of the Chicago > meeting so we have a concrete proposal for asymmetric keys? > > > > Thanks, > > Kathleen > > Please excuse typos, sent from handheld device > > > On Nov 17, 2016, at 11:26 PM, Rene Struik <rstruik....@gmail.com> wrote: > > Dear colleagues: > > Just a reminder re perceived technical hurdles for using signatures: > a) time latency of signing: > One can pre-compute ephemeral signing keys, so as to reduce online key > computation to a few finite field multiplies. > Please see my email to the list of July 26, 2016: > https://mailarchive.ietf.org/arch/msg/ace/iEb0XnAIMAB_V3I8LjMFQRj1Fe0 > b): further speed-ups/tricks, etc: > One can try and be smarter by clever implementations. > Please see my email to the list of July 21, 2016: > https://mailarchive.ietf.org/arch/msg/ace/iI58mT_DDzKImL1LP_bUQ7TzooI > > This seems to take the time latency argument away. The only other > technical hurdles I can see are > (i) signature size {is 64B too much?}; > (ii) cost of public key crypto implementations {quite some small, nifty > designs out there (NaCl etc.}. > > As to (i) - one should view signature sizes in perspective: as an example, > key sizes in the key pre-distribution scheme HIMMO (as promoted by Philips) > has key sizes of 6.25 kB and up, according to Table 3 of the paper that > massages parameters to thwart new attacks on their scheme, see > http://eprint.iacr.org/2016/152. > > So, security arguments that favor asymmetric solutions aside, there also > do not seem to be too many other objections that would hold in the world > anno 2016 {except for "sunk investment" arguments", but that is a corporate > mindset issue}. > > On 11/17/2016 12:50 AM, Michael StJohns wrote: > > On 11/16/2016 9:08 AM, Kepeng Li wrote: > > Hello all, > > We had a long discussion about group communication security topic since > the previous F2F meeting. > > Hannes and I have tried to make a summary about the discussion as follows: > > · The solution needs to define both, symmetric and an asymmetric > group key solution. > > > There is no case (absent hardware mitigation) in which a symmetric group > key solution can be made secure/safe and no one has made an offer of proof > that they can make it secure. I've asked repeatedly - no one has come > forward with more than "oh we can lock the symmetric key stuff in a corner > and make sure it isn't used for anything important". > > > Given the recent attacks on the internet by IOT botnets, there is a > further consideration that should be undertaken - whether the symmetric > group key solution applied to 10s of 1000s of IOT devices is an active > threat to the rest of the internet (e.g. enabling DDOS, cyber physical > issues, etc)? > > The multiparty (group) symmetric key solution is only wanted for a single > corner of the solution space - low latency, no cost systems. E.g. > lightbulbs. Given there is a worked example of the insecurity of > multiparty symmetric key systems (e.g. the attack on the symmetric signing > key of the HUE lights), I'm unclear why anyone at all would think that > pursuing a known bad solution in the IETF is a good idea. > > > · The security consideration section needs to explain under what > circumstances what solution is appropriate. > > > Security consideration sections generally only address the threat *to* the > system from security choices. In this case, symmetric key group comms > reduces down to the same security analysis you would use with shared > default passwords across 1000s of devices. An IOT security consideration > section in the future probably needs to address the threat *FROM* the IOT > solution to the broader internet. > > Mike > > > > If this is not accurate, please let us know. > > Kind Regards > Kepeng & Hannes > > BTW: it is a pity that I can't attend this meeting due to personal > reasons, and hope you all have a nice meeting in Seoul! > > > > > _______________________________________________ > > 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 > > > > > > -- > > email: rstruik....@gmail.com | Skype: rstruik > > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 > > _______________________________________________ > 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
