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

Michael StJohns <mstjohns@comcast.net> Sun, 13 November 2016 01:36 UTC

Return-Path: <mstjohns@comcast.net>
X-Original-To: ace@ietfa.amsl.com
Delivered-To: ace@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BB2FC1296C3 for <ace@ietfa.amsl.com>; Sat, 12 Nov 2016 17:36:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.197
X-Spam-Level:
X-Spam-Status: No, score=-4.197 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, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=comcast.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 24JOC-1rlOjC for <ace@ietfa.amsl.com>; Sat, 12 Nov 2016 17:35:56 -0800 (PST)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8D1B1296BD for <ace@ietf.org>; Sat, 12 Nov 2016 17:35:55 -0800 (PST)
Received: from resomta-ch2-18v.sys.comcast.net ([69.252.207.114]) by resqmta-ch2-10v.sys.comcast.net with SMTP id 5ji5coALRRing5ji7czb1S; Sun, 13 Nov 2016 01:35:55 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20140121; t=1479000955; bh=bDYUTHtwYBr+IkC9wXH9uYLtsLxY4fcx9PejxCzE+UA=; h=Received:Received:Subject:To:From:Message-ID:Date:MIME-Version: Content-Type; b=DGOiITufn023jIeLiHSdT2EnysHwqbW19L0XUx5AXlmSLnMkmt90Iyw3ZXn5zIJ6C L0IFN3dcVs8Wol8FJF8P7aZP8KJOAeY+Ql6n46RTAdzNx1j9XeMQh7plFiySDvJDeH cMI1BkZ7ajYyzDU9MTfPLR6IWTGDAMseX5qNuPZidxtPBzvYbxG1sPVTsQCDP3Eprr 81uWknqJ+TTNnqWEPM/9A/MVBxUA8+ngbVjPTVCOB/iLSOpXt1bYIozaHXX73iFfs7 DQaNiuvWuEu8/ULMkeqC9eO+VGbna6wtMazBIzOdC1+aE67Xl8EnX4xst7XkxEiAWP lmvB6e4w06sqA==
Received: from [31.133.134.205] ([31.133.134.205]) by resomta-ch2-18v.sys.comcast.net with SMTP id 5jhucVdC5TAgy5jhxc0dIT; Sun, 13 Nov 2016 01:35:52 +0000
To: Michael Richardson <mcr+ietf@sandelman.ca>, ace@ietf.org
References: <D40F1535.451DD%kepeng.lkp@alibaba-inc.com> <1cc7f243-e7f7-6ec5-7140-88c74853dc34@gmx.net> <04FDEBEF-68CF-4DC6-B760-4DFB1B87D22C@gmail.com> <b69552fc-97c1-bc8f-6282-c3d42bf081c0@comcast.net> <6108.1478988687@dooku.sandelman.ca>
From: Michael StJohns <mstjohns@comcast.net>
Message-ID: <187ea38f-3271-ee91-7053-3e5ecedeafea@comcast.net>
Date: Sat, 12 Nov 2016 20:35:48 -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: <6108.1478988687@dooku.sandelman.ca>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-CMAE-Envelope: MS4wfCZVa9jMdOmiN7Zc9m2p9JF4WOomjJSPOGeF4L0Nk02IA0yXxk1/WfgKv+r1jBXVBZeKeuYbCiIPu5OVXSvT1c85CpnxK4KvdWdqLnQhBqwYktwzKcni OhhQVtVi2udC7Gu0H7fvpdwLyUUGmuOcAxLy7FkujF2c5fbRsolEHusAn16/DSJn0mBf0VxrbyOW6mndX7LImSQXLs+7z1yot0c=
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/QpG8Qk9UqmztyQRmu8XnytmHf6k>
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion
X-BeenThere: ace@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Authentication and Authorization for Constrained Environments \(ace\)" <ace.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ace>, <mailto:ace-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ace/>
List-Post: <mailto:ace@ietf.org>
List-Help: <mailto:ace-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ace>, <mailto:ace-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 13 Nov 2016 01:36:07 -0000

On 11/12/2016 5:11 PM, Michael Richardson wrote:
> I realize that this thread is months old: I haven't seen any newer
> conversation, so I'll continue anyway.
>
> I would concur with MSJ's view that having an informational draft might be a
> way to let this work go forward, but I suggest instead the right track might
> be experimental.
I suggested Informational as the IETF has a long history of republishing 
things developed elsewhere as "Here's how we did it documents".  
Experimental documents generally describe ideas either where we know 
there is a way forward, but we're not sure which of several paths work, 
or ideas where the general utility may not be readily apparent.    I 
could live with experimental/non-WG.

> I'm less sure that I agree with the subsequent view that we can't adopt this
> item until we have assurance; I'd say that asking for the issue to be
> addressed as part of the adoption process is reasonable, and objecting at
> WGLC if it has not been addressed is the right way.

http://www.techworm.net/2016/11/researchers-use-drones-hijack-philips-hue-smart-lights.html 
describes how the use of multi-party symmetric key systems weakens even 
minimal security guarantees in a IOT system.  In this article, its noted 
that the HUE lights have firmware that's signed/encrypted by a symmetric 
key (which - by definition then needs to be included in every device to 
decrypt/verify the firmware), and that the attackers were able to 
extract the key from a lightbulb with relative ease; craft their own 
firmware and cause the lightbulbs to load it in a chain reaction.

There really isn't a lot of difference in the key extraction attack for 
the above vs extracting a symmetric key used for group communications.  
The only saving grace in group comms is that the group is smaller than 
unity.

So I'd turn this around and ask for a offer of proof that we can find a 
way to do this safely *BEFORE* having the IETF invest time and resources 
in the work.  I don't expect a fully fleshed out solution, but I haven't 
seen even a hint that anyone knows how to mitigate the risks.



>
> I will say I'm scared that garage door actuators and doors and security
> systems will be sold with "lighting" interfaces.  This same thing happened in
> USB space: zillions of inappropriate USB devices were given HID designations
> because the windows drivers were easier to write/get-signed.
>

At least most of those weren't cyber physical (except maybe the USB nerf 
turret and its ilk 
http://weburbanist.com/2009/11/18/truly-geeky-gadgets-15-usb-weapons-from-fail-to-fantastic/).

Mike