Re: [Dtls-iot] DTLS multicast security

Carsten Bormann <cabo@tzi.org> Fri, 19 September 2014 15:44 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 DF7961A01F1 for <dtls-iot@ietfa.amsl.com>; Fri, 19 Sep 2014 08:44:42 -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 IkqbeJEHfw0E for <dtls-iot@ietfa.amsl.com>; Fri, 19 Sep 2014 08:44:41 -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 27C391A01CA for <dtls-iot@ietf.org>; Fri, 19 Sep 2014 08:44:41 -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 s8JFic7b004735 for <dtls-iot@ietf.org>; Fri, 19 Sep 2014 17:44:38 +0200 (CEST)
Received: from [10.0.1.3] (reingewinn.informatik.uni-bremen.de [134.102.218.123]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B7F733C; Fri, 19 Sep 2014 17:44:37 +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: <541C452D.9090302@nthpermutation.com>
Date: Fri, 19 Sep 2014 17:44:37 +0200
X-Mao-Original-Outgoing-Id: 432834277.01362-8f11e0874ebc6e0bd3fd4e814d80cb88
Content-Transfer-Encoding: quoted-printable
Message-Id: <EBE85F86-00E2-40F8-9205-1B6AE20CAAE9@tzi.org>
References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <541BD0E0.1090409@sics.se> <36F5869FE31AB24485E5E3222C288E1FFAFA@NABESITE.InterDigital.com> <541C452D.9090302@nthpermutation.com>
To: dtls-iot@ietf.org
X-Mailer: Apple Mail (2.1878.6)
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/zuGh42A1XeR8CCL9BX7Oi1pE8pQ
Subject: Re: [Dtls-iot] 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, 19 Sep 2014 15:44:43 -0000

On 19 Sep 2014, at 17:01, Michael StJohns <msj@nthpermutation.com> wrote:

>> I agree with Ludwig that having a secure multicast is considered a benefit by many.
> My problem with this statement is that I would consider anti-gravity to be a benefit to many, but that AG has exactly the same scientific basis as symmetric key multicast security - none.  There's long, long experience on this topic that the document writers have ignored.

This discussion is a great demonstration that the IETF is unfit to do appropriate security.

Yes, there is no known way to do efficient multicast security at military security levels*).

I’m not interested in military security.
The use cases I’m interested in need neither nonrepudiation nor do they need to address a threat model that involves tampering with devices.

draft-mglt-dice-ipsec-for-application-payload demonstrates that we already have the IETF protocols in place to do appropriate security here.

All the various Philips proposals tried to do was to package this functionality in a way that fits better to the other security protocols that DICE is trying to improve.  (And, yes, that work wasn’t finished before it was derailed.)

If we cannot continue this work because it wouldn’t solve other use cases we don’t care about, that would be rather disappointing.

Grüße, Carsten

*) TESLA is not solving our problem either.