Re: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-08.txt

Carsten Bormann <cabo@tzi.org> Tue, 08 July 2014 16:05 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 8F9851B2B77 for <dtls-iot@ietfa.amsl.com>; Tue, 8 Jul 2014 09:05:06 -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 y0udpMPqKtNE for <dtls-iot@ietfa.amsl.com>; Tue, 8 Jul 2014 09:05:06 -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 A29981B2B6F for <dtls-iot@ietf.org>; Tue, 8 Jul 2014 09:05:05 -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 s68G4uDq017178; Tue, 8 Jul 2014 18:04:56 +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 2EB7D80F; Tue, 8 Jul 2014 18:04:56 +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: <53BC12A1.7070602@nthpermutation.com>
Date: Tue, 08 Jul 2014 18:04:55 +0200
X-Mao-Original-Outgoing-Id: 426528295.097179-86cd7f2ee2c6104b2cc522ff36a2adbe
Content-Transfer-Encoding: quoted-printable
Message-Id: <79DC6CBB-9738-4197-8983-39DEB83C737C@tzi.org>
References: <20140703125443.15822.61762.idtracker@ietfa.amsl.com> <BE6D13F6A4554947952B39008B0DC0153E7CB29C@DBXPRD9003MB059.MGDPHG.emi.philips.com> <53BAC656.7010008@nthpermutation.com> <BE6D13F6A4554947952B39008B0DC0153E7CF9CC@DBXPRD9003MB059.MGDPHG.emi.philips.com> <53BC051D.9000907@nthpermutation.com> <0D0BF288-244F-46A8-9BD3-53A79C7B9525@tzi.org> <53BC12A1.7070602@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/z3uZ_6FYoHncNsJ0XSM94ifiYCo
Cc: "Kumar, Sandeep" <sandeep.kumar@philips.com>, "dtls-iot@ietf.org" <dtls-iot@ietf.org>
Subject: Re: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-08.txt
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: Tue, 08 Jul 2014 16:05:06 -0000

I consider a definition of (integrity) protection more useful that figures in the attacker.
If an attacker can steal a lamp out of my home and tamper with it, I probably have larger issues than whether they can do some morse code on my lights.  (If they can “hack” it, they already can do the morse code thing.)
So, yes, I consider group keying to provide integrity protection — against attackers outside the group.

> application-based group keying is still significant progress for those cases where the attack model doesn’t rule out group keying.
> 
> The use cases where this works all seem to involve a secure processing element and that's not exactly within the DICE charter.

Tamper-proofing is not required for the above use case.

> The most successful group keying system I'm aware of is pay TV (either satellite or cable).  Those systems - obviously - use a secure processing element (e.g. smart card or built in) to manage group keys and decryption based on credentials.

This has a quite different attack model — here you hand over the entire environment (smart card, decoder) to any interested attacker.  This is not the case we are interested in.

> I literally can't think of a use case without an SPE where the attack model doesn't rule out group keying for integrity protection and most attack models for most use cases rule it out for confidentiality.

See above.

Grüße, Carsten