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

"Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com> Fri, 18 November 2016 03:56 UTC

Return-Path: <tireddy@cisco.com>
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 820C81294B9 for <ace@ietfa.amsl.com>; Thu, 17 Nov 2016 19:56:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.517
X-Spam-Level:
X-Spam-Status: No, score=-15.517 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RCVD_IN_SORBS_SPAM=0.5, RP_MATCHES_RCVD=-1.497, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
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 dTBsFczZyB8c for <ace@ietfa.amsl.com>; Thu, 17 Nov 2016 19:56:13 -0800 (PST)
Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DB181293D6 for <ace@ietf.org>; Thu, 17 Nov 2016 19:56:13 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22110; q=dns/txt; s=iport; t=1479441373; x=1480650973; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=0U0fKjEmPuGoZcfsbKfY9nxCwZ0LvHJsxwthT5k91t0=; b=Z7pgSR+UJgpqz72mYYBsS7OS812Z8WUdtqBQxiiBe2fXyrFg1NEkIp4L ODqQtJ5fmVd0rclOGnR079WLAbQc7TfIe9rIFjwajPU45QiiodSi/0E/S j+zgkDN32dM6lvOY2Zu5QYIwIPDEQNIdbNQdvBLyB9hg4iIlIhgXag5M4 s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0AlAQBney5Y/4YNJK1bAxkBAQEBAQEBAQEBAQcBAQEBAYJzRAEBAQEBH1iBAAeNOJcQh2+HW4UbggcdAQqFeQIagXo/FAECAQEBAQEBAWIohGgBAQEEAQEBIApBCxACAQgRBAEBKAMCAgIfBgsUCQgCBAENBQgTiDcDFw6sKoIph0UNhAUBAQEBAQEBAQEBAQEBAQEBAQEBAQEchjyEWoJIgVMRATMKFRGCPYJdBYhGiluGbzUBhj+GYoNFgXdPhCeJQIdggUiEKoQKAQ8PN10uHYUhcgGGHIEhgQwBAQE
X-IronPort-AV: E=Sophos;i="5.31,655,1473120000"; d="scan'208,217";a="172652233"
Received: from alln-core-12.cisco.com ([173.36.13.134]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 18 Nov 2016 03:56:12 +0000
Received: from XCH-ALN-018.cisco.com (xch-aln-018.cisco.com [173.36.7.28]) by alln-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id uAI3uCsb022459 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 18 Nov 2016 03:56:12 GMT
Received: from xch-rcd-017.cisco.com (173.37.102.27) by XCH-ALN-018.cisco.com (173.36.7.28) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 17 Nov 2016 21:56:11 -0600
Received: from xch-rcd-017.cisco.com ([173.37.102.27]) by XCH-RCD-017.cisco.com ([173.37.102.27]) with mapi id 15.00.1210.000; Thu, 17 Nov 2016 21:56:11 -0600
From: "Tirumaleswar Reddy (tireddy)" <tireddy@cisco.com>
To: "kathleen.moriarty.ietf@gmail.com" <kathleen.moriarty.ietf@gmail.com>, Rene Struik <rstruik.ext@gmail.com>
Thread-Topic: [Ace] Summary of ACE Group Communication Security Discussion
Thread-Index: AQHSF95O4Mh/TThK60uX2f7HbJa1j6CL8WcAgAAWPYCAADVxAIBRUHeOgAEE04D//9zDkA==
Date: Fri, 18 Nov 2016 03:56:11 +0000
Message-ID: <dead56f965b94081bd187585d1272398@XCH-RCD-017.cisco.com>
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> <187ea38f-3271-ee91-7053-3e5ecedeafea@comcast.net> <7f461eca-b294-4a4f-b8e1-ec2fe70effaf.kepeng.lkp@alibaba-inc.com> <3ccde008-1e19-718d-37bb-ed7653c60ec9@comcast.net> <c4ec1408-8453-e056-05d6-1aa4d0aeb105@gmail.com> <0C27644B-6033-4781-86D5-2FD66872CEFC@gmail.com>
In-Reply-To: <0C27644B-6033-4781-86D5-2FD66872CEFC@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.65.76.218]
Content-Type: multipart/alternative; boundary="_000_dead56f965b94081bd187585d1272398XCHRCD017ciscocom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/_UYOHdy6EXImzLOujcKIHtKwGls>
Cc: Michael StJohns <mstjohns@comcast.net>, "ace@ietf.org" <ace@ietf.org>
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: Fri, 18 Nov 2016 03:56:15 -0000

Kathleen,

I will put up a proposal before the Chicago meeting.

-Tiru

From: Ace [mailto:ace-bounces@ietf.org] On Behalf Of kathleen.moriarty.ietf@gmail.com
Sent: Friday, November 18, 2016 5:30 AM
To: Rene Struik <rstruik.ext@gmail.com>
Cc: Michael StJohns <mstjohns@comcast.net>; ace@ietf.org
Subject: Re: [Ace] Summary of ACE Group Communication Security Discussion

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.ext@gmail.com<mailto:rstruik.ext@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<mailto:Ace@ietf.org>

https://www.ietf.org/mailman/listinfo/ace






_______________________________________________

Ace mailing list

Ace@ietf.org<mailto:Ace@ietf.org>

https://www.ietf.org/mailman/listinfo/ace




--

email: rstruik.ext@gmail.com<mailto:rstruik.ext@gmail.com> | Skype: rstruik

cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
_______________________________________________
Ace mailing list
Ace@ietf.org<mailto:Ace@ietf.org>
https://www.ietf.org/mailman/listinfo/ace