Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security)

Carsten Bormann <cabo@tzi.org> Fri, 03 October 2014 19:29 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: dtls-iot@ietfa.amsl.com
Delivered-To: dtls-iot@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 38E8B1A1A79 for <dtls-iot@ietfa.amsl.com>; Fri, 3 Oct 2014 12:29:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.551
X-Spam-Level:
X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=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 ka89FjjR1dIC for <dtls-iot@ietfa.amsl.com>; Fri, 3 Oct 2014 12:29:23 -0700 (PDT)
Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (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 7CB811A887F for <dtls-iot@ietf.org>; Fri, 3 Oct 2014 12:29:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s93JTKOL026752; Fri, 3 Oct 2014 21:29:20 +0200 (CEST)
Received: from [172.20.10.7] (ip-109-45-1-252.web.vodafone.de [109.45.1.252]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3253981; Fri, 3 Oct 2014 21:29:18 +0200 (CEST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.6\))
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <542EF272.7060909@nthpermutation.com>
Date: Fri, 03 Oct 2014 21:29:15 +0200
X-Mao-Original-Outgoing-Id: 434057355.770591-846ec371de73a4720963757335245630
Content-Transfer-Encoding: quoted-printable
Message-Id: <4D1BC205-3C21-47AF-A472-9F8ABF507B4F@tzi.org>
References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <542EBA5D.5090105@gmail.com> <E9A3CFC3-DE3D-4751-930C-2722E64FC292@gmail.com> <542EF272.7060909@nthpermutation.com>
To: Michael StJohns <msj@nthpermutation.com>
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/OR8oEoVa-YRB3UpdnQE9aofREgk
Cc: dtls-iot@ietf.org
Subject: Re: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security)
X-BeenThere: dtls-iot@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DTLS for IoT discussion list <dtls-iot.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dtls-iot/>
List-Post: <mailto:dtls-iot@ietf.org>
List-Help: <mailto:dtls-iot-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dtls-iot>, <mailto:dtls-iot-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 03 Oct 2014 19:29:25 -0000

On 03 Oct 2014, at 21:01, Michael StJohns <msj@nthpermutation.com> wrote:

> What I think we got was consensus that symmetric key multicast control wasn't going to fly and that symmetric key multicast confidentiality might be useful.

Control is not a security service.
I don’t think there is consensus that group authentication is not useful.
In any case, it is hard to do confidentiality without some form of authentication.

I live in a world where the loudly stated arguments about group authentication being dangerous and asymmetric crypto being “cheap" just don’t apply.  Apparently, I have been unable to show some of you this world.  I just spent another two days in a workshop on systems and products where this is so patently obvious that words escape me.  So I don’t think we can have consensus between the IoT security view and the loudly stated military/banking security view here.

draft-mglt-dice-ipsec-for-application-payload-00 demonstrates that existing IETF standards track protocols suffice to solve the problem at hand, except maybe for a lack of optimization.  So maybe this is where those interested in solving this problem need to continue their work.

Grüße, Carsten