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
_______________________________________________ Ace mailing list Ace@ietf.org https://www.ietf.org/mailman/listinfo/ace