From nobody Tue Apr 1 09:35:24 2014 Return-Path: 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 DECBB1A0852 for ; Tue, 1 Apr 2014 09:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.962 X-Spam-Level: X-Spam-Status: No, score=0.962 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 cHfCX2oDnuRM for ; Tue, 1 Apr 2014 09:35:20 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 1EBCC1A0505 for ; Tue, 1 Apr 2014 09:35:19 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s31GMII7015780 for ; Tue, 1 Apr 2014 18:35:15 +0200 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jr6a9v6ax-1 for ; Tue, 01 Apr 2014 18:35:15 +0200 Received: from mail-we0-f180.google.com (mail-we0-f180.google.com [74.125.82.180]) (Authenticated sender: marco@sics.se) by letter.sics.se (Postfix) with ESMTPSA id 7421840116 for ; Tue, 1 Apr 2014 18:35:15 +0200 (CEST) Received: by mail-we0-f180.google.com with SMTP id p61so6478537wes.39 for ; Tue, 01 Apr 2014 09:35:14 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:date:message-id:subject:from:to:content-type; bh=wX6aWGmugpAtl/INANi4xrAFWaRo8QscCXqhle9VBoQ=; b=eDuFp4Zw3Euy/HhDhi6yVO0yHDwBL/1qgjZl+EweIw6yPvtZMl9H973G8vDmESypkl M0qSbsX9hC962odvDSmaM5mKYKGWu7N5l4ocjGnGNi9dJlU0+27rG2qKE9Mv5tvybAJF P/S7q31hE3LmAo5kVu5y3fLrvLTgybY9nDQgIknoNj2urg1Gos6Q73xssDwaw2y7WEAJ PJ9qdXT1qa+WSFWqTdtEuE0OEW7S1Cj3rlrZl4QJ+VVvMAGFySn1HN8x96jLok0DKoUs u0WV9Vs/6NkQ9wvCNksdpRyGCfQPYvQcM5G2YB3Cb1YpSmmYXfhkCIl4Ulgr8u4H+yeE vB/g== MIME-Version: 1.0 X-Received: by 10.194.203.170 with SMTP id kr10mr24028695wjc.19.1396370114943; Tue, 01 Apr 2014 09:35:14 -0700 (PDT) Received: by 10.194.172.105 with HTTP; Tue, 1 Apr 2014 09:35:14 -0700 (PDT) Date: Tue, 1 Apr 2014 18:35:14 +0200 Message-ID: From: Marco Tiloca To: dtls-iot@ietf.org Content-Type: multipart/alternative; boundary=047d7b6d87dead222f04f5fdc09c X-Proofpoint-Spam-Reason: safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-04-01_05:2014-04-01,2014-04-01,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/YQWt0KexcMQufk7PFvFPiRly0t4 Subject: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Apr 2014 16:35:23 -0000 --047d7b6d87dead222f04f5fdc09c Content-Type: text/plain; charset=ISO-8859-1 Dear all, As to possible responses to multicast requests, Section 2.1 states that they are sent back in unicast. Then, no further details are provided about their protection. Are such responses supposed to be protected through a "regular" DTLS session, which must be (or has previously been) established between the sender and listener? Cheers, Marco --047d7b6d87dead222f04f5fdc09c Content-Type: text/html; charset=ISO-8859-1
Dear all,

As to possible responses to multicast requests, Section 2.1 states that they are sent back in unicast. Then, no further details are provided about their protection.

Are such responses supposed to be protected through a "regular" DTLS session, which must be (or has previously been) established between the sender and listener?

Cheers,
Marco




--047d7b6d87dead222f04f5fdc09c-- From nobody Wed Apr 2 00:46:51 2014 Return-Path: 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 3B3361A0168 for ; Wed, 2 Apr 2014 00:46:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.101 X-Spam-Level: X-Spam-Status: No, score=0.101 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 jhUe6dWAleDJ for ; Wed, 2 Apr 2014 00:46:43 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe003.messaging.microsoft.com [216.32.180.13]) by ietfa.amsl.com (Postfix) with ESMTP id 5265C1A016A for ; Wed, 2 Apr 2014 00:46:43 -0700 (PDT) Received: from mail128-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE003.bigfish.com (10.7.40.23) with Microsoft SMTP Server id 14.1.225.23; Wed, 2 Apr 2014 07:46:39 +0000 Received: from mail128-va3 (localhost [127.0.0.1]) by mail128-va3-R.bigfish.com (Postfix) with ESMTP id 4602C4C0298; Wed, 2 Apr 2014 07:46:39 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.240.53; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -27 X-BigFish: VPS-27(z579ehz15d6O9371Ic85fhe0eah9251I217bIdd85kzz1f42h1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6h208chzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25f6h2605h268bh26d3h1155h) Received: from mail128-va3 (localhost.localdomain [127.0.0.1]) by mail128-va3 (MessageSwitch) id 139642479731041_30164; Wed, 2 Apr 2014 07:46:37 +0000 (UTC) Received: from VA3EHSMHS026.bigfish.com (unknown [10.7.14.249]) by mail128-va3.bigfish.com (Postfix) with ESMTP id F27B01E0062; Wed, 2 Apr 2014 07:46:36 +0000 (UTC) Received: from mail.philips.com (206.191.240.53) by VA3EHSMHS026.bigfish.com (10.7.99.36) with Microsoft SMTP Server (TLS) id 14.16.227.3; Wed, 2 Apr 2014 07:46:36 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.240]) by DBXPRD9003HT003.MGDPHG.emi.philips.com ([141.251.25.208]) with mapi id 14.16.0423.000; Wed, 2 Apr 2014 07:46:32 +0000 From: "Kumar, Sandeep" To: Marco Tiloca , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05 Thread-Index: AQHPTchhm7+YxKyF2EiKYxVcXZ3UGJr98qZQ Date: Wed, 2 Apr 2014 07:46:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E5CAD9FDBXPRD9003MB059_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/9oP07VAN6cIVh7ppmEs2G9oF3WU Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 07:46:48 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E5CAD9FDBXPRD9003MB059_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi Marco The draft only addresses the protection of multicast traffic. If unicast re= sponses are expected and if protection is required for such messages, then = existing unicast protection mechanisms based on DTLS as suggested in draft-= ietf-core-coap-18 should be used. Protection of all unicast messages should= be treated as would be done normally. Hope that answers your question. Regards Sandeep From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Marco Tiloca Sent: Tuesday, April 01, 2014 6:35 PM To: dtls-iot@ietf.org Subject: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security= -05 Dear all, As to possible responses to multicast requests, Section 2.1 states that the= y are sent back in unicast. Then, no further details are provided about the= ir protection. Are such responses supposed to be protected through a "regular" DTLS sessio= n, which must be (or has previously been) established between the sender an= d listener? Cheers, Marco ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_BE6D13F6A4554947952B39008B0DC0153E5CAD9FDBXPRD9003MB059_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi Marco

 <= /p>

The draft only addresses = the protection of multicast traffic. If unicast responses are expected and = if protection is required for such messages, then existing unicast protection mechanisms based on DTLS as suggested in draft-ietf-cor= e-coap-18 should be used. Protection of all unicast messages should be trea= ted as would be done normally.

 <= /p>

Hope that answers your qu= estion.

 <= /p>

Regards=

Sandeep

 <= /p>

From: dtls-iot= [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Marco Tiloca
Sent: Tuesday, April 01, 2014 6:35 PM
To: dtls-iot@ietf.org
Subject: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-s= ecurity-05

 

Dear all,

 

As to possible responses to multicast requests, Sect= ion 2.1 states that they are sent back in unicast. Then, no further details= are provided about their protection.

 

Are such responses supposed to be protected through = a "regular" DTLS session, which must be (or has previously been) = established between the sender and listener?

 

Cheers,

Marco

 

 

 

 


The information contained in= this message may be confidential and legally protected under applicable la= w. 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 i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_BE6D13F6A4554947952B39008B0DC0153E5CAD9FDBXPRD9003MB059_-- From nobody Wed Apr 2 09:22:25 2014 Return-Path: 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 8D6661A02CE for ; Wed, 2 Apr 2014 09:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.559 X-Spam-Level: X-Spam-Status: No, score=-1.559 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, T_RP_MATCHES_RCVD=-0.01] 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 zjOOl49thHpk for ; Wed, 2 Apr 2014 09:22:17 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id AEEE31A02D4 for ; Wed, 2 Apr 2014 09:22:16 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s32G9rNb013526 for ; Wed, 2 Apr 2014 18:22:11 +0200 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jr6a9xh3b-1 for ; Wed, 02 Apr 2014 18:22:11 +0200 Received: from [192.168.1.10] (unknown [39.54.245.29]) (Authenticated sender: shahid@sics.se) by letter.sics.se (Postfix) with ESMTPSA id AB23740116; Wed, 2 Apr 2014 18:22:08 +0200 (CEST) From: Shahid Raza Content-Type: multipart/alternative; boundary="Apple-Mail=_4D1BD124-6AD1-41E8-988C-F74D1236E237" Message-Id: <8AA354BC-78FF-4051-AF8E-9C723AA54874@sics.se> Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) Date: Wed, 2 Apr 2014 21:22:05 +0500 References: <4D6EDE04-5315-48F3-93C5-2B9E9D5625B6@sics.se> To: dtls-iot@ietf.org X-Mailer: Apple Mail (2.1874) X-Proofpoint-Spam-Reason: safe X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-04-02_03:2014-04-02,2014-04-02,1970-01-01 signatures=0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/qGk1zE3R-K31wbLPhilPfhOkQtY Cc: Shahid Raza Subject: [Dtls-iot] Fwd: New Draft Notification - [draft-raza-dice-compressed-dtls-00] X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 02 Apr 2014 16:22:23 -0000 --Apple-Mail=_4D1BD124-6AD1-41E8-988C-F74D1236E237 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii It would be great if IETFers in the DICE WP provide us reviews on this = draft.=20 /Shahid Begin forwarded message: > From: Shahid Raza > Subject: [Dtls-iot] New Draft Notification - = [draft-raza-dice-compressed-dtls-00] > Date: 21 Mar 2014 15:13:18 GMT+5 > To: dtls-iot@ietf.org > Cc: Shahid Raza , "Olivier Dupont \(odupont\)" = , Hossein Shafagh >=20 > Dear All, >=20 > A new draft is submitted to the DICE Working Group.=20 > http://tools.ietf.org/html/draft-raza-dice-compressed-dtls-00 >=20 > This work provides a lightweight CoAPs by compressing the underneath = DTLS protocol with 6LoWPAN header compression mechanisms. With DTLS = header compression we achieve energy efficiency by reducing the message = size, since communication requires more energy than computation. Also, = it avoids 6LoWPAN fragmentation that is applied when the size of = datagram is larger than the link layer MTU. Our compressed DTLS = maintains true End-to-End (E2E) security between resource constrained = hosts in 6LoWPAN networks and typical Internet hosts that use = uncompressed CoAPs. >=20 > Regards > Shahid >=20 > --------------------------------------------------------------- > Shahid Raza > PhD, Senior Researcher > Networked Embedded Systems group > Swedish Institute of Computer Science (SICS) > SICS Swedish ICT, Stockholm, Sweden > Ph. No. +46 768831797 > http://www.shahidraza.info >=20 > Research Interests: IoT, Security, WSNs > --------------------------------------------------------------- >=20 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot --Apple-Mail=_4D1BD124-6AD1-41E8-988C-F74D1236E237 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii It = would be great if IETFers in the DICE WP provide us reviews on this = draft. 

/Shahid

Begin = forwarded message:

From: Shahid Raza <shahid@sics.se>
Subject: [Dtls-iot] New Draft Notification = - [draft-raza-dice-compressed-dtls-00]
Date: 21 Mar 2014 15:13:18 = GMT+5
Cc: Shahid Raza <aazan@ciit.net.pk>, "Olivier = Dupont \(odupont\)" <odupont@cisco.com>, Hossein = Shafagh <shafagh@inf.ethz.ch>
=
Dear All,

A new = draft is submitted to the DICE Working Group. 
<= br>
This work provides a lightweight CoAPs by compressing the = underneath DTLS protocol with 6LoWPAN header compression mechanisms. =  With DTLS header compression we achieve energy efficiency by = reducing the message size, since communication requires more energy than = computation. Also,  it avoids 6LoWPAN fragmentation that is applied = when the size of datagram is larger than the link layer MTU. Our = compressed DTLS maintains true End-to-End (E2E) security between = resource constrained hosts in 6LoWPAN networks and typical Internet = hosts that use uncompressed = CoAPs.

Regards
Shahid

---------------------------------------------------------------=
Shahid Raza
 Stockholm, Sweden
Ph. = No. +46 768831797

Research Interests: IoT, Security, = WSNs
dtls-iot@ietf.org
https://www.iet= f.org/mailman/listinfo/dtls-iot

= --Apple-Mail=_4D1BD124-6AD1-41E8-988C-F74D1236E237-- From nobody Thu Apr 3 10:52:43 2014 Return-Path: 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 BB1781A0104 for ; Thu, 3 Apr 2014 10:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] 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 v5mHYQamZMXK for ; Thu, 3 Apr 2014 10:52:34 -0700 (PDT) Received: from mail-qc0-f172.google.com (mail-qc0-f172.google.com [209.85.216.172]) by ietfa.amsl.com (Postfix) with ESMTP id 2EAF91A0264 for ; Thu, 3 Apr 2014 10:52:34 -0700 (PDT) Received: by mail-qc0-f172.google.com with SMTP id i8so2289706qcq.31 for ; Thu, 03 Apr 2014 10:52:29 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Mv3O2K0i2DuC+A2uxFTjMocb5OWsigZ3UZzZNw69LKU=; b=kr7p1LjHMFwPtA7UFR42Xwe3dOdQcPXwi2s8Sd2klHAaE9USIZu28f6mzkMrqV39SI 3epVYC5Mw6x9iZwHddbvk92lSxKWLcUG4yi1W1X+DU5SkQpeR/VEhpG8GB0ti9n8iE4F 7jdkrguQb01KuQEMVnRWYFrCP/ApBoM8HB5F5Bx00ap9QgZYXdnSucge4XOgRLZRu+Rd bcz4cIu8Wq1XvsRsg/KN2KGqDvLzeU5cL1F2FqhPfM7t8y5NrtjOCI1sMDbpv4eUtDCq tKc5gozMahmAQiTrReoCETHfDaOLQDeHgHzFKkg/TW06OXO9cmYRgAKjNw02V/kDhxJ8 /E1g== X-Gm-Message-State: ALoCoQlVP7tWyuzYh2QSvhLi2kwkPzaYqvliZItBGH8SpMildWM7t/25o1Ow4RXLmKcm2fBVvmQD X-Received: by 10.140.50.231 with SMTP id s94mr8416952qga.33.1396547549690; Thu, 03 Apr 2014 10:52:29 -0700 (PDT) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id g7sm11307832qaf.14.2014.04.03.10.52.28 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 03 Apr 2014 10:52:29 -0700 (PDT) Message-ID: <533D9FE0.1050105@nthpermutation.com> Date: Thu, 03 Apr 2014 13:52:32 -0400 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <4D6EDE04-5315-48F3-93C5-2B9E9D5625B6@sics.se> <8AA354BC-78FF-4051-AF8E-9C723AA54874@sics.se> In-Reply-To: <8AA354BC-78FF-4051-AF8E-9C723AA54874@sics.se> Content-Type: multipart/alternative; boundary="------------070908040808070505060604" Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/8xrIdBgB68KPXfDWms9aSruLyKA Subject: Re: [Dtls-iot] Fwd: New Draft Notification - [draft-raza-dice-compressed-dtls-00] X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 03 Apr 2014 17:52:40 -0000 This is a multi-part message in MIME format. --------------070908040808070505060604 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 4/2/2014 12:22 PM, Shahid Raza wrote: > It would be great if IETFers in the DICE WP provide us reviews on this > draft. > > /Shahid A couple of quick notes: While the DICE folks should certainly look at this, given that this is all about 6Lowpan header compression, it may be more useful to move it forward in the 6lowpan group. Among other reasons - the expertise to evaluate this is more about the 6lowpan than it is about DTLS. During the last TLS f2f meeting, and given current discussions on the TLS mailing list, it's unclear that compression is on the table for the future of TLS due to various attacks related to compression. This may or may not impact consideration of this draft. With respect to the document approach related to DTLS there are a few possible gotchas: 1) Cipher Suite compression - this ties the draft to a specific COAP required cipher suite - TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as a default. That makes that suite somewhat mandatory to implement, and leaves some issues with respect to how to deal with regional cipher suites requirements as well as futures. Given the relatively small size of a cipher suite spec (2 bytes), and given a possible loss of flexibility, it's unclear that this is a reasonable field to compress. Also, that suite uses - I believe - the HMAC-SHA-256 as the PRF. I understand the goal is to get to an IOT implementation that only needs to implement the block encrypt function of AES so that suite may be the wrong suite to specify as a default. 2) Compression Methods compression - given the discussion on the TLS list it may be useful in the DICE DTLS profile to just ban TLS style compression for DICE DTLS. That's a separate discussion from the 6lowpan dtls header and protocol compression. 3) Section 4 - next to last paragraph - "The length field of the handshake headers is always omitted as it can be deduced from the lower layers" - I don't think I have a big problem with deducing length from 6lowpan even though that's a layer violation, but I would object to the need to look at the 802.15.4 header as that's far outside the IETF's scope and changes that happen there could be problematic. Maybe note that 802.15.4 has a header compression scheme, and that it losslessly recovers the IPv6 6lowpan datagram and leave it at that? 4) This document needs a section describing when and in what order compression and decompression and other calculations happen - e.g. form the normal DTLS datagram, calculate the MIC, THEN compress the dtls headers THEN calculate the UDP checksum THEN compress the UDP headers then compress the IP headers. Mike > > Begin forwarded message: > >> *From: *Shahid Raza > >> *Subject: **[Dtls-iot] New Draft Notification - >> [draft-raza-dice-compressed-dtls-00]* >> *Date: *21 Mar 2014 15:13:18 GMT+5 >> *To: *dtls-iot@ietf.org >> *Cc: *Shahid Raza >, >> "Olivier Dupont \(odupont\)" > >, Hossein Shafagh > > >> >> Dear All, >> >> A new draft is submitted to the DICE Working Group. >> http://tools.ietf.org/html/draft-raza-dice-compressed-dtls-00 >> >> This work provides a lightweight CoAPs by compressing the underneath >> DTLS protocol with 6LoWPAN header compression mechanisms. With DTLS >> header compression we achieve energy efficiency by reducing the >> message size, since communication requires more energy than >> computation. Also, it avoids 6LoWPAN fragmentation that is applied >> when the size of datagram is larger than the link layer MTU. Our >> compressed DTLS maintains true End-to-End (E2E) security between >> resource constrained hosts in 6LoWPAN networks and typical Internet >> hosts that use uncompressed CoAPs. >> >> Regards >> Shahid >> >> --------------------------------------------------------------- >> Shahid Raza >> PhD, Senior Researcher >> Networked Embedded Systems group >> Swedish Institute of Computer Science (SICS) >> *SICS Swedish ICT,*Stockholm, Sweden >> Ph. No. +46 768831797 >> http://www.shahidraza.info >> >> Research Interests: IoT, Security, WSNs >> --------------------------------------------------------------- >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot > > > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot --------------070908040808070505060604 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 4/2/2014 12:22 PM, Shahid Raza wrote:
It would be great if IETFers in the DICE WP provide us reviews on this draft. 

/Shahid

A couple of quick notes:

While the DICE folks should certainly look at this, given that this is all about 6Lowpan header compression, it may be more useful to move it forward in the 6lowpan group.  Among other reasons - the expertise to evaluate this is more about the 6lowpan than it is about DTLS. 

During the last TLS f2f meeting, and given current discussions on the TLS mailing list, it's unclear that compression is on the table for the future of TLS due to various attacks related to compression.  This may or may not impact consideration of this draft.

With respect to the document approach related to DTLS there are a few possible gotchas:

1) Cipher Suite compression - this ties the draft to a specific COAP required cipher suite - TLS_ECDHE_ECDSA_WITH_AES_128_CCM_8 as a default.  That makes that suite somewhat mandatory to implement, and leaves some issues with respect to how to deal with regional cipher suites requirements as well as futures.  Given the relatively small size of a cipher suite spec (2 bytes), and given a possible loss of flexibility, it's unclear that this is a reasonable field to compress. 

Also, that suite uses - I believe - the HMAC-SHA-256 as the PRF.  I understand the goal is to get to an IOT implementation that only needs to implement the block encrypt function of AES so that suite may be the wrong suite to specify as a default.

2) Compression Methods compression - given the discussion on the TLS list it may be useful in the DICE DTLS profile to just ban TLS style compression for DICE DTLS.  That's a separate discussion from the 6lowpan dtls header and protocol compression.

3) Section 4 - next to last paragraph - "The length field of the handshake headers is always omitted as it can be deduced from the lower layers" - I don't think I have a big problem with deducing length from 6lowpan even though that's a layer violation, but I would object to the need to look at the 802.15.4 header as that's far outside the IETF's scope and changes that happen there could be problematic.  Maybe note that 802.15.4 has a header compression scheme, and that it losslessly recovers the IPv6 6lowpan datagram and leave it at that? 

4) This document needs a section describing when and in what order compression and decompression and other calculations  happen -

e.g.   form the normal DTLS datagram, calculate the MIC, THEN compress the dtls headers THEN calculate the UDP checksum THEN compress the UDP headers then compress the IP headers.

Mike



Begin forwarded message:

From: Shahid Raza <shahid@sics.se>
Subject: [Dtls-iot] New Draft Notification - [draft-raza-dice-compressed-dtls-00]
Date: 21 Mar 2014 15:13:18 GMT+5
Cc: Shahid Raza <aazan@ciit.net.pk>, "Olivier Dupont \(odupont\)" <odupont@cisco.com>, Hossein Shafagh <shafagh@inf.ethz.ch>

Dear All,

A new draft is submitted to the DICE Working Group. 

This work provides a lightweight CoAPs by compressing the underneath DTLS protocol with 6LoWPAN header compression mechanisms.  With DTLS header compression we achieve energy efficiency by reducing the message size, since communication requires more energy than computation. Also,  it avoids 6LoWPAN fragmentation that is applied when the size of datagram is larger than the link layer MTU. Our compressed DTLS maintains true End-to-End (E2E) security between resource constrained hosts in 6LoWPAN networks and typical Internet hosts that use uncompressed CoAPs.

Regards
Shahid

---------------------------------------------------------------
Shahid Raza
PhD, Senior Researcher
Networked Embedded Systems group
Swedish Institute of Computer Science (SICS)
SICS Swedish ICT, Stockholm, Sweden
Ph. No. +46 768831797
http://www.shahidraza.info

Research Interests: IoT, Security, WSNs
---------------------------------------------------------------

_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot



_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.org/mailman/listinfo/dtls-iot

--------------070908040808070505060604--