Re: [Ace] Group Communication Security Disagreements

"Grunwald, Markus" <M.Grunwald@osram.com> Thu, 28 July 2016 13:15 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 DE7BD12D786 for <ace@ietfa.amsl.com>; Thu, 28 Jul 2016 06:15:06 -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 0R-f-6RX3LtL for <ace@ietfa.amsl.com>; Thu, 28 Jul 2016 06:15:02 -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 7B28B12D181 for <ace@ietf.org>; Thu, 28 Jul 2016 06:15:02 -0700 (PDT)
Received: from mailout-m.osram.net (mailout-m.osram.net [88.217.131.24]) by rly31a.srv.mailcontrol.com (MailControl) with ESMTPS id u6SDD0cF072325 (version=TLSv1 cipher=AES128-SHA bits=128 verify=FAIL) for <ace@ietf.org>; Thu, 28 Jul 2016 14:14:59 +0100
Received: from exc-mchpop.mch.osram.de (172.21.147.130) by EXC-MCHHC01.mch.osram.de (172.21.145.231) with Microsoft SMTP Server (TLS) id 8.3.444.0; Thu, 28 Jul 2016 15:14:27 +0200
Received: from EXC-MCHMBX33.mch.osram.de ([10.138.56.31]) by exc-mchpop.mch.osram.de ([172.21.147.130]) with mapi; Thu, 28 Jul 2016 15:14:27 +0200
From: "Grunwald, Markus" <M.Grunwald@osram.com>
To: "ace@ietf.org" <ace@ietf.org>
Date: Thu, 28 Jul 2016 15:14:25 +0200
Thread-Topic: [Ace] Group Communication Security Disagreements
Thread-Index: AdHoXZhNg+4so3YARjytuRKrlqVi6QAbr5hQ
Message-ID: <4D6B5484A4456C4684818BBF9B04AC2133162F8ECB@EXC-MCHMBX33.mch.osram.de>
References: <57909032.10809@gmx.net> <6d259c5b-28e3-c748-4590-0c9f942fe343@comcast.net> <378a0359-6b31-a30c-af28-8ea567b06b00@cisco.com> <57963480.2000809@gmx.net> <0d4c6d56-ebb5-2f43-d555-29c336396033@ericsson.com> <15169.1469642303@obiwan.sandelman.ca> <CAHbuEH4u=AF1LSoDq+YfLwt+VX1OOrj54331GuZmyjLswHvNnw@mail.gmail.com> <3271.1469656595@obiwan.sandelman.ca> <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net>
In-Reply-To: <32aa7104-70df-80c7-8d6e-537b66716de9@comcast.net>
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_4D6B5484A4456C4684818BBF9B04AC2133162F8ECBEXCMCHMBX33mc_"
MIME-Version: 1.0
X-Scanned-By: MailControl 44278.1378 (www.mailcontrol.com) on 10.65.0.141
Archived-At: <https://mailarchive.ietf.org/arch/msg/ace/-rKfHqOpRU--0vggDojtLxNwxTE>
Subject: Re: [Ace] Group Communication Security Disagreements
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: Thu, 28 Jul 2016 13:15:07 -0000

Hello,

Let's do this the right way.  Let's not bow to the "tyranny of the light switch" in accepting solutions that are NOT secure, even for the limited scope they are proposing.

Later, Mike

If this is a bait, I’ll bite ;)

I think everybody already agreed that private/public key encryption is the way for a bullet proofed group communication. But there are other questions:

-        Does it have to be bullet proofed?

-        How are applications handled that are not able to provide private/public key encryption?

I may (most possibly) have missed something, but the only answer that you seem to accept is “public key encryption”, period. Then let me ask directly: how should systems that have to reply in a tight margin be handled? People will simply not buy a lighting solution where the light will switch on 500ms after you pressed the switch. They will lough at this “solution”.

So, throw more hardware at it? For light switches that cost €100, adding a crypto chip for ¢50 might not be a problem. But there are parts like ECG where ¢2 matter. One of them will be in every luminaire…

This means, there are systems that cannot afford to provide public key encryption. Do you want an IoT without light? Let’s not bow to the “discrimination of the light switch”, at least not for the parking house/ parking lot. An Airport is a different beast.

Mit freundlichen Grüßen

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