IETF Logo Mail Archive

Re: [Dtls-iot] DTLS multicast security

"Kumar, Sandeep" <sandeep.kumar@philips.com> Tue, 23 September 2014 11:09 UTC

Return-Path: <sandeep.kumar@philips.com>
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 55DFD1A1A8F for <dtls-iot@ietfa.amsl.com>; Tue, 23 Sep 2014 04:09:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001] autolearn=ham
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 C6oUJBwm3YYR for <dtls-iot@ietfa.amsl.com>; Tue, 23 Sep 2014 04:09:10 -0700 (PDT)
Received: from emea01-db3-obe.outbound.protection.outlook.com (mail-db3on0710.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe04::710]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8BA1B1A7034 for <dtls-iot@ietf.org>; Tue, 23 Sep 2014 04:09:09 -0700 (PDT)
Received: from DBXPR04CA0021.eurprd04.prod.outlook.com (10.141.8.149) by AM3PR04MB0630.eurprd04.prod.outlook.com (10.255.133.151) with Microsoft SMTP Server (TLS) id 15.0.1034.13; Tue, 23 Sep 2014 11:08:44 +0000
Received: from DB3FFO11FD044.protection.gbl (2a01:111:f400:7e04::126) by DBXPR04CA0021.outlook.office365.com (2a01:111:e400:9414::21) with Microsoft SMTP Server (TLS) id 15.0.1034.13 via Frontend Transport; Tue, 23 Sep 2014 11:08:44 +0000
Received: from mail.philips.com (206.191.240.52) by DB3FFO11FD044.mail.protection.outlook.com (10.47.217.75) with Microsoft SMTP Server (TLS) id 15.0.1029.15 via Frontend Transport; Tue, 23 Sep 2014 11:08:44 +0000
Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.201]) by DBXPRD9003HT001.MGDPHG.emi.philips.com ([141.251.25.206]) with mapi id 14.16.0469.000; Tue, 23 Sep 2014 11:08:43 +0000
From: "Kumar, Sandeep" <sandeep.kumar@philips.com>
To: Ludwig Seitz <ludwig@sics.se>, "dtls-iot@ietf.org" <dtls-iot@ietf.org>
Thread-Topic: [Dtls-iot] DTLS multicast security
Thread-Index: AQHP04DrqofHcYLhrUe3gH/qVs6rT5wIA2cAgABPEQCAADuTgIAADC6AgAAEjQCAAATOAIAABM8AgAAGcQCAAA05gIAEpV2AgAAR7wCAAN+dgIAAPd2g
Date: Tue, 23 Sep 2014 11:08:43 +0000
Message-ID: <BE6D13F6A4554947952B39008B0DC0153E86F614@DBXPRD9003MB059.MGDPHG.emi.philips.com>
References: <6D27AD8D-3B90-4100-9440-3375946F420B@gmail.com> <541BD0E0.1090409@sics.se> <36F5869FE31AB24485E5E3222C288E1FFAFA@NABESITE.InterDigital.com> <541C452D.9090302@nthpermutation.com> <EBE85F86-00E2-40F8-9205-1B6AE20CAAE9@tzi.org> <541C5336.9040406@nthpermutation.com> <394E30E1-378D-4F37-B86D-F05297A2D8B6@tzi.org> <541C5B46.8060406@nthpermutation.com> <2819E45A-6B1B-4B14-8A7E-3B9358AA3B12@tzi.org> <541C6BC5.7070308@nthpermutation.com> <5420517B.60502@tzi.de> <54206086.1040707@nthpermutation.com> <54211C1B.6000509@sics.se>
In-Reply-To: <54211C1B.6000509@sics.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [194.171.252.100]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:206.191.240.52; CTRY:US; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(428002)(85714005)(13464003)(24454002)(55904004)(51704005)(479174003)(189002)(377454003)(199003)(105586002)(31966008)(92726001)(106116001)(15975445006)(54356999)(107046002)(21056001)(76482002)(50986999)(76176999)(97736003)(120916001)(69596002)(10300001)(92566001)(68736004)(101416001)(95666004)(77096002)(64706001)(99396002)(66066001)(106466001)(81156004)(74502003)(83322001)(83072002)(20776003)(85852003)(6806004)(15202345003)(47776003)(90102001)(74662003)(80022003)(19580395003)(33656002)(55846006)(86362001)(23756003)(2656002)(16601075003)(46102003)(107886001)(81542003)(77982003)(104016003)(79102003)(19580405001)(81342003)(4396001)(85306004)(44976005)(87936001)(84676001)(93886004)(50466002)(567094001); DIR:OUT; SFP:1102; SCL:1; SRVR:AM3PR04MB0630; H:mail.philips.com; FPR:; MLV:sfv; PTR:ErrorRetry; MX:1; A:1; LANG:en;
X-Microsoft-Antispam: UriScan:;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:;SRVR:AM3PR04MB0630;
X-Forefront-PRVS: 0343AC1D30
Received-SPF: None (protection.outlook.com: philips.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is 206.191.240.52) smtp.mailfrom=sandeep.kumar@philips.com;
X-OriginatorOrg: philips.com
Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/AEbkmhgqF0CtXjBTf0el8h--t6I
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: Tue, 23 Sep 2014 11:09:12 -0000

I think there is more to it
A) only confidentiality
B) Integrity
        B.1) All devices are equal in the group (all members are senders and receivers)
        B.2) There is an asymmetric relation in the devices of the group (only some members are senders)

For A and B.1 symmetric crypto would be sufficient
B.2 requires asymmetric crypto to perform authorizations.

If there is no bar to stupidity then independent of whichever crypto primitive one chooses, one can always  implement things insecurely.
Implementers can even share the same public-private key pairs on different devices(certificates are expensive) or just put the private key everywhere although the implementer should have only put the public-keys. And these kind of artificial arguments can be constructed not just for multicast security but for any protocol in IETF.

I think B.2 should be resolved as part of ACE.  DICE can still work on A and B.1 (with or without DTLS).

Regards
Sandeep

> -----Original Message-----
> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Ludwig Seitz
> Sent: Tuesday, September 23, 2014 9:07 AM
> To: dtls-iot@ietf.org
> Subject: Re: [Dtls-iot] DTLS multicast security
>
> On 09/22/2014 07:46 PM, Michael StJohns wrote:
> ....
> > If you use multicast symmetric key systems only for confidentiality,
> > breaking in to a node to extract the key doesn't give you much more
> > than you already had - the multicast traffic destined for the node you
> > just hacked.  So things like multicast audio aren't necessarily
> > identity-important cases.
> >
> Aha!
>
> So would it be acceptable to separate the problem?
>
> A.) A protocol for multicast confidentiality in CoRE (with or without DTLS, I
> don't care)
>
> B.) A protocol for authorizing control messages (whether they are
> multicasted or not)
>
> Where this work would be done is another question, B. seems like a task for
> ACE.
>
> Would A.) alone be beneficial enough to justify working on it?
>
> /Ludwig
>
>
>
>
>
> --
> Ludwig Seitz, PhD
> SICS Swedish ICT AB
> Ideon Science Park
> Building Beta 2
> Scheelevägen 17
> SE-223 70 Lund
>
> Phone +46(0)70-349 92 51
> http://www.sics.se


________________________________
The information contained in this message may be confidential and legally protected under applicable law. The message is intended solely for the addressee(s). If you are not the intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message is strictly prohibited and may be unlawful. If you are not the intended recipient, please contact the sender by return e-mail and destroy all copies of the original message.

v2.23.0 | Report a Bug | By Email