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

Michael StJohns <> Thu, 17 November 2016 05:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6F93F12964F for <>; Wed, 16 Nov 2016 21:50:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.196
X-Spam-Status: No, score=-4.196 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, RP_MATCHES_RCVD=-1.497, 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 7O35_GUjmrcc for <>; Wed, 16 Nov 2016 21:50:06 -0800 (PST)
Received: from ( [IPv6:2001:558:fe21:29:69:252:207:39]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1AEE31295DB for <>; Wed, 16 Nov 2016 21:50:06 -0800 (PST)
Received: from ([]) by with SMTP id 7FaHceyI4ff8q7FaHcf85a; Thu, 17 Nov 2016 05:50:05 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=q20140121; t=1479361805; bh=HqUzktnwyRNFQwJUpeizMexl8ntv4RVlN0pbYofE1lA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=WfyfRNEoqWukNest935+cilB7NumKrO7PrQYhHw54IZ1qp8lRzjf9PmMi8orpVyMY NfLwtkOnFOZZJB40ox/FMzk/PBlDbx7fqznrLjYdEKLt5wBj6Nj5dwhDQ2klROa/lF 88ofP68tALMuxITZX66V33WXQSTJ+zq1ARf5o/u0ycPJa2uLyZOK8qA8p5eSjKw5+b kye4ajGeqzGRde63GKftFXrRyEXXios6PLQrDLT6WCM8Ye2ETRuVrvI+FJ4+a+CGqq e9sIZ1uGy9PUnRVIRfZ6ku1jWgCbPWjbHRDm4MpoLTtONEXLnibmsjVOyucz7Q0+yN XgFi/KRFeW67A==
Received: from [IPv6:2001:67c:370:144:a89a:c353:cdd3:bb57] ([IPv6:2001:67c:370:144:a89a:c353:cdd3:bb57]) by with SMTP id 7Fa3cXeHP0G8A7Fa9cG7t9; Thu, 17 Nov 2016 05:50:03 +0000
References: <> <> <> <> <> <> <>
From: Michael StJohns <>
Message-ID: <>
Date: Thu, 17 Nov 2016 00:50:00 -0500
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------ACD31C6068427B0031E57060"
X-CMAE-Envelope: MS4wfIDzl/X61oBxOpbteDQ1jlR5bCWjL25VdPb1OEp0yIZTiiUjV43SkqsW/x52ErG/gdImx0S1Tq2t7y65vsm2i+wjNbs+go81D2AJ6qeN0N+uItIGxVwE paddy5A7YG89DUfXZtcBTkDyDEqVwRj4eXdUD3vaNEGYo4zSOTHsRIcYME40cCuPlwKbwdeC9Mm7Ng==
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 05:50:08 -0000

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.


> 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