Re: [Ace] Summary of ACE Group Communication Security Discussion

Rene Struik <> Thu, 17 November 2016 14:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6DE7512996A for <>; Thu, 17 Nov 2016 06:26:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.699
X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id CQp70-smB5VK for <>; Thu, 17 Nov 2016 06:26:45 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c0b::233]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4D9AB1297ED for <>; Thu, 17 Nov 2016 06:26:45 -0800 (PST)
Received: by with SMTP id c20so280500910itb.0 for <>; Thu, 17 Nov 2016 06:26:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to; bh=sDBWNg/98qKI05rIaujMuUlj1d3I9XE4R8OnLtRx9Cg=; b=ZJ4FUJbpqDvDTV6wuf8FDATZCK6lkaTT+YTZVHb30bg8mM1KsCJfvmrI/dnndXxOMz e+vzPmP3qTWkNYsz2hWEyYpKfNqFuPQPdP8LqRS9LCq+I5s8veNUsOSzadFBpFBztEM+ 9PlJTldwtf2HqFJzENyTGvwfAbuqyrubyJ2/SRMDtiv4yV0M/4JvASDGLRCdef2FanKd RbQYkFAQsqBDIOStkhXmryxE7GYvgbzY1f4Pi45KD+/OT7wu9d4NdeBy1dasAcr0pobF aERV8nQ/fGfTK1dDffMqMnAX9ddofrldcmzfWGKXYu6zyLZSUAxx8UZHYR7FxUJ2aD4t Fkmw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to; bh=sDBWNg/98qKI05rIaujMuUlj1d3I9XE4R8OnLtRx9Cg=; b=JABXbi+dgGn+qO5R+3DsvtDJXjF09IogJZK8tJOS0PeAPIqCxZnJ7NahS4r/4tOp/f KyAECMfg/rh64TeMlSQGCZxP4RSGbdmxEjFDFiTI03jJLoBEMkS/KjMeEtyu/Lq7f3N3 03NpoME2A3wOV0ORrNoZcIGstxzaTtQuPv862E9uf0V5qwAypgj8RPck5dURbum0RwSd 2iYkf/5MelLkWX7pL68tXM3jieLtLm4LxrU8kvQ07tEk+OwgMXEZ0CVPtLZvbtFf2Ysl UOsp2McdCBV200IW2Xsve8RW60kJlrP87vGB/SiaknARxw2XU6LQ11z2nm/6CrBtgcar ijNw==
X-Gm-Message-State: AKaTC01qt1u8gBfTtvz0OUJ4DJKzl6dSIiIEZ/ujWnGbiRH6/pQ8KMJEZI+1Q6diT3TsBA==
X-Received: by with SMTP id u35mr3071385ioi.124.1479392803929; Thu, 17 Nov 2016 06:26:43 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id s13sm1307916ioi.24.2016. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 17 Nov 2016 06:26:43 -0800 (PST)
To: Michael StJohns <>,
References: <> <> <> <> <> <> <> <>
From: Rene Struik <>
Message-ID: <>
Date: Thu, 17 Nov 2016 09:26:32 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------9059CEC1217759B97667B1B0"
Archived-At: <>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 17 Nov 2016 14:26:47 -0000

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:
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:

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, 

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 mailing list

email: | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363