IETF Logo Mail Archive

Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE

"Grunwald, Markus" <M.Grunwald@osram.com> Wed, 27 July 2016 12:34 UTC

Return-Path: <M.Grunwald@osram.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 14F8812E140 for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 05:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001] autolearn=ham autolearn_force=no
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 MdDXlxXxXrQ8 for <ace@ietfa.amsl.com>; Wed, 27 Jul 2016 05:34:25 -0700 (PDT)
Received: from cluster-a.mailcontrol.com (cluster-a.mailcontrol.com [85.115.52.190]) (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 E683612E13C for <ace@ietf.org>; Wed, 27 Jul 2016 05:34:22 -0700 (PDT)
Received: from mailout-mn.osram.net (mailout-mn.osram.net [62.245.131.35]) by rly05a.srv.mailcontrol.com (MailControl) with ESMTPS id u6RCYJHb109586 (version=TLSv1 cipher=AES128-SHA bits=128 verify=NO); Wed, 27 Jul 2016 13:34:19 +0100
Received: from EXC-MCHMBX33.mch.osram.de ([10.138.56.31]) by EXC-MCHHC02.mch.osram.de ([172.21.145.233]) with mapi; Wed, 27 Jul 2016 14:34:19 +0200
From: "Grunwald, Markus" <M.Grunwald@osram.com>
To: "ace@ietf.org" <ace@ietf.org>
Date: Wed, 27 Jul 2016 14:34:17 +0200
Thread-Topic: RE: Adoption of Low Latency Group Communication Security Work in ACE
Thread-Index: AdHoAjmRKpKl99ElRsqMLSHOEvT9DQ==
Message-ID: <4D6B5484A4456C4684818BBF9B04AC2133162422D5@EXC-MCHMBX33.mch.osram.de>
Accept-Language: de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE
Content-Type: multipart/alternative; boundary="_000_4D6B5484A4456C4684818BBF9B04AC2133162422D5EXCMCHMBX33mc_"
MIME-Version: 1.0
X-Scanned-By: MailControl 44278.1378 (www.mailcontrol.com) on 10.65.0.115
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/CPQ0rbqSW1v-alqwgF3XOnzBo30>
Subject: Re: [Ace] Adoption of Low Latency Group Communication Security Work in ACE
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: Wed, 27 Jul 2016 12:35:32 -0000

Hello,

sorry to break the threading by not replying directly to a post, but until now I have only been reading the list passively. So I have no mail to reply to...

I followed your discussion regarding group multicast and how to encrypt them. I see the problem, but I think one single approach to solve it either way will not be enough:


-        The 200ms barrier for lighting products is quite fix. If we build products with a reaction time that is too long, nobody is going to use it.

-        On the other hand, I am scared of IoT products that could have bigger latency, but still use a somewhat weaker crypto. I'm thinking of Fire/Smokedetectors at big airports or the like. Even toggling all lights of an airport in a one-second rhythm could cause huge problems.

-        So we need both, but can hardly have it.

For me, this leads to multiple security levels:

1)      Basic security: fast response, low cost with lower security: use symmetric keys. Use this where the risk is low.

2)      High security, low cost: Allow slow(er) response times, because of the ECC calculations. Kind of a compromise...

3)      High security, higher cost: add some crypto hardware. For high risk environments with low latency

I don't think that we will be able to cover the whole range of requirements with one single approach. Implementing the lowest level would be relatively easy for first concepts.

Best regards,

Markus Grunwald
Development Engineer

OSRAM GmbH
DS D LMS-COM DE-1
Parkring 33
85748 Garching, Deutschland
Tel. +49 89 6213-3678
mailto:M.Grunwald@osram.com
www.osram.com

Bitte prüfen Sie der Umwelt zuliebe, ob der Ausdruck dieser Mail erforderlich ist!

OSRAM GmbH: Vorsitzender des Aufsichtsrates: Peter Bauer; Geschäftsführung: Dr. Olaf Berlien (Vorsitzender), Dr. Stefan Kampmann;
Sitz der Gesellschaft: München; Registergericht: München, HRB 201526; WEEE-Reg.-Nr. DE 71568000

v2.23.0 | Report a Bug | By Email