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

Reply via email to