From zach.shelby@arm.com Wed Oct 2 20:25:03 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7203021F9F96 for ; Wed, 2 Oct 2013 20:25:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wFK1Nm2LwN5S for ; Wed, 2 Oct 2013 20:24:52 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 73FB221F9AE2 for ; Wed, 2 Oct 2013 20:24:48 -0700 (PDT) Received: from usa-sjc-gw2.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Thu, 03 Oct 2013 04:24:46 +0100 Received: from Spock.usa.Arm.com ([fe80::f144:5416:1a75:7083]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Wed, 2 Oct 2013 20:24:44 -0700 From: Zach Shelby To: "dtls-iot@ietf.org" Date: Wed, 2 Oct 2013 20:24:42 -0700 Thread-Topic: [Dtls-iot] DICE wg approved and chairs.... Thread-Index: Ac6/6Bp2tgAnKL+3R72LhWnIIF9tOw== Message-ID: <7CA0C114-BC04-46C1-84C2-56A022754AEB@arm.com> References: <5245B4D5.1030107@cs.tcd.ie> In-Reply-To: <5245B4D5.1030107@cs.tcd.ie> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US MIME-Version: 1.0 X-MC-Unique: 113100304244604902 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Subject: Re: [Dtls-iot] DICE wg approved and chairs.... X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 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 Oct 2013 03:25:03 -0000 I just wanted to welcome everyone to DICE on my behalf, great work and part= icipation from everyone running up to the BOF! We are going to be encouraging the authors of our current straw-man Interne= t Drafts to continue working on their drafts and to soon submit new version= s taking feedback received before and during IETF Berlin. We had a good num= ber of hands come up (about 10+ I believe) of folks interested to either co= ntribute to these work items as an author or by providing comments. If you = are motivated to get involved with either DTLS profiling or the Multicast w= ork, now would be a good time to provide reviews to the authors or propose = text contributions. As a reminder, we had two straw-man drafts that did a good job of summarisi= ng the problem and possible solution: DTLS profiling: http://tools.ietf.org/html/draft-keoh-dtls-profile-iot-00 Multicast DTLS record layer: http://www.ietf.org/id/draft-keoh-dtls-multica= st-security-00.txt And of course we encourage people to submit new Internet Drafts on any work= the group would find useful related to DTLS optimisation, uses of DTLS in = IoT, wish-lists for DTLS v1.3 and the multicast DTLS record layer design. T= his also gives you a chance to present your work in Vancouver at the WG mee= ting, we will be requiring a submitted ID in order to get a presentation sl= ot! Regards, Zach On Sep 27, 2013, at 9:39 AM, Stephen Farrell wr= ote: > > Hi all, > > The IESG approved the creation of the DICE working group > on our call yesterday. I'll be sending the final approval > announcement to the secretariat shortly and then you'll > see the formal annoucement popping out in a day or so. > > I'm delighted to say that Zach Shelby (Zach.Shelby@arm.com) > and Dorothy Gellert (dgellert@silverspringnet.com) have > agreed to co-chair the group. Zach most of you will > know already from the BoF, and Dorothy has previously > chaired security area working groups and has lots of > experience with the IETF and security technologies, so > together they bring all the right experience to help > you make this a successful wg. Thanks to Zach and Dorothy > for being willing to chair! > > I'd also like to thank Carsten for co-chairing the BoF. > I think he and Zach and all the other folks who > contributed did a really great job with that. > > I requested a 90 minute session for DICE at IETF-88 in > Vancouver so I look forward to seeing lots of progress > on the list before then and to seeing those of you that > can travel at that session. > > So, you'll be hearing from Zach and Dorothy shortly to > get stuff going, > Cheers, > Stephen. > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot Zach Shelby Director of Technology ARM Internet of Things BU www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: fi.linkedin.com/in/zachshelby/ -- IMPORTANT NOTICE: The contents of this email and any attachments are con= fidential and may also be privileged. If you are not the intended recipient= , please notify the sender immediately and do not disclose the contents to = any other person, use it for any purpose, or store or copy the information = in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: 2548782 From cabo@tzi.org Sat Oct 5 09:31:27 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771B821F8616; Sat, 5 Oct 2013 09:31:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.949 X-Spam-Level: X-Spam-Status: No, score=-105.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tj7XAJn+DN-u; Sat, 5 Oct 2013 09:31:21 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 1BC1521F8447; Sat, 5 Oct 2013 09:31:20 -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.4/8.14.4) with ESMTP id r95GVIrR013568; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Received: from [192.168.217.105] (p54892064.dip0.t-ipconnect.de [84.137.32.100]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 58C9ECAC; Sat, 5 Oct 2013 18:31:18 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: Date: Sat, 5 Oct 2013 18:31:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: lwip@ietf.org, "core@ietf.org WG" , roll WG , 6lowpan@ietf.org, "dtls-iot@ietf.org" , "6lo@ietf.org WG" <6lo@ietf.org>, IETF 6TSCH <6tsch@ietf.org> X-Mailer: Apple Mail (2.1510) Subject: [Dtls-iot] Constrained Node/Network Cluster @ IETF88, early draft version X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Oct 2013 16:31:27 -0000 A first draft version of the IETF88 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution,=20 so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 All times are PST (UTC-0800). The Constrained Node/Network group meetings are nicely spread out over = the week. The lwig/6tisch conflict is unfortunate; this will split the audience. The oauth conflict on Monday is survivable, we'll do all = security-related CoRE work on Thursday then. Gr=FC=DFe, Carsten MONDAY, November 4, 2013 0900-1130 Morning Session I Georgia B APP appsawg Applications Area Working Group WG - - = Combined with APPAREA Regency D INT 6man IPv6 Maintenance WG 1300-1430 Afternoon Session I Regency B SEC *** dice DTLS In Constrained Environments WG 1450-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG Regency C INT intarea Internet Area Working Group WG Plaza C SEC oauth Web Authorization Protocol WG 1740-1940 Afternoon Session III Regency A APP httpbis Hypertext Transfer Protocol Bis WG Regency D OPS v6ops IPv6 Operations WG Regency C RTG rtgarea Routing Area Open Meeting TUESDAY, November 5, 2013 0900-1130 Morning Session I Georgia A APP httpbis Hypertext Transfer Protocol Bis WG 1300-1400 Afternoon Session I Plaza A APP json JavaScript Object Notation WG Regency B INT its Intelligent Transportation Systems BOF 1420-1550 Afternoon Session II Georgia B INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Regency A INT *** lwig Light-Weight Implementation Guidance WG Regency B TSV tsvwg Transport Area Working Group WG 1610-1840 Afternoon Session III Regency A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Plaza A OPS eman Energy Management WG Georgia A SEC tls Transport Layer Security WG WEDNESDAY, November 6, 2013 1300-1530 Afternoon Session I Regency C OPS v6ops IPv6 Operations WG Regency D SEC perpass Handling Pervasive Monitoring in the = IETF BOF Georgia B TSV rmcat RTP Media Congestion Avoidance = Techniques WG THURSDAY, November 7, 2013 0900-1130 Morning Session I Regency D INT homenet Home Networking WG Georgia A SEC jose Javascript Object Signing and Encryption = WG Regency C TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Regency D SEC saag Security Area Open Meeting 1520-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG FRIDAY, November 8, 2013 0900-1100 Morning Session I Regency D RTG *** roll Routing Over Low power and Lossy = networks WG Georgia B SEC httpauth Hypertext Transfer Protocol = Authentication WG Regency B TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG 1230-1330 Afternoon Session II Regency D INT dnssd Extensions for Scalable DNS Service = Discovery WG From cabo@tzi.org Mon Oct 7 08:08:55 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B256A11E8147 for ; Mon, 7 Oct 2013 08:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.228 X-Spam-Level: X-Spam-Status: No, score=-106.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Pr8yYDuphlZm for ; Mon, 7 Oct 2013 08:08:51 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id B709B11E8155 for ; Mon, 7 Oct 2013 08:08:40 -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.4/8.14.4) with ESMTP id r97F8bOJ012634 for ; Mon, 7 Oct 2013 17:08:37 +0200 (CEST) Received: from [192.168.217.105] (p548900EB.dip0.t-ipconnect.de [84.137.0.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5119537E; Mon, 7 Oct 2013 17:08:37 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: <20131007144053.16131.80399.idtracker@ietfa.amsl.com> Date: Mon, 7 Oct 2013 17:08:36 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131007144053.16131.80399.idtracker@ietfa.amsl.com> To: "dtls-iot@ietf.org" X-Mailer: Apple Mail (2.1510) Subject: [Dtls-iot] draft-hartke-dice-practical-issues-00.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:08:55 -0000 Nice draft. A couple of quick comments: [DCOSS12] does *not* use GHC, instead they invent a header compression = format not unlike the one in the draft (which fits into the RFC 6282 NHC = scheme just like GHC does). GHC happens to outperform the DCOSS12 scheme in many cases, because it = looks at the whole packet, so it also compresses the cipher suite = specific header. Any attempt to get good compression should make use of = this somewhat surprising result. Gr=FC=DFe, Carsten On Oct 7, 2013, at 16:40, internet-drafts@ietf.org wrote: >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : Practical Issues with Datagram Transport Layer = Security in Constrained Environments > Author(s) : Klaus Hartke > Filename : draft-hartke-dice-practical-issues-00.txt > Pages : 23 > Date : 2013-10-07 >=20 > Abstract: > This document investigates practical issues around the = implementation > of Datagram Transport Layer Security (DTLS) in constrained > environments, and explores some ideas for an optimized version of > DTLS that is more friendly to constrained nodes and networks. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-hartke-dice-practical-issues >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-hartke-dice-practical-issues-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From hartke@tzi.org Mon Oct 7 08:33:48 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 440B021E8087 for ; Mon, 7 Oct 2013 08:33:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.627 X-Spam-Level: X-Spam-Status: No, score=-5.627 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mS5ghhSJmAeE for ; Mon, 7 Oct 2013 08:33:42 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D54221E8099 for ; Mon, 7 Oct 2013 08:33:40 -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.4/8.14.4) with ESMTP id r97FXbCc015405 for ; Mon, 7 Oct 2013 17:33:37 +0200 (CEST) Received: from mail-ve0-f181.google.com (mail-ve0-f181.google.com [209.85.128.181]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id DB2703A3 for ; Mon, 7 Oct 2013 17:33:36 +0200 (CEST) Received: by mail-ve0-f181.google.com with SMTP id oy12so3902607veb.12 for ; Mon, 07 Oct 2013 08:33:35 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=bQr4itI8qrpDy6q4XWWmPxj1+iLikW4SRvL/twfXXe0=; b=hZf05Teliuok/kJDkaIw6X9R5qRpFEQWo5owe6+X3WJN3Y4E8jj/DVXUAXX7Ixl7YH eBwF0n+l4Mu3+sor7VsjPuXFqnJXlAZXbNF0WX+LCJjVWS0l15C2As6ZqQXMhYGvdL4I ec2NB/TB2xYo85mUPn1JrT9Iii08o66Cef+pWvgi+LEBBI6yE0LYP5wXuO1aV8AJqo8Q fqMAkiKBYlPK1lw5udR7hb6ayk4eFrQhJBQaVsp8cW90RBSok6elCaK6l/7QDxp6TFfK PnaWZDMR2aVUVN4wHYSkBjQLOBreE4OgQTDaVsMElzZSPlouEnBiLMGPMxar+1rSC7Gc gDtA== X-Received: by 10.58.218.225 with SMTP id pj1mr990244vec.24.1381160015526; Mon, 07 Oct 2013 08:33:35 -0700 (PDT) MIME-Version: 1.0 Received: by 10.52.24.83 with HTTP; Mon, 7 Oct 2013 08:32:55 -0700 (PDT) In-Reply-To: References: <20131007144053.16131.80399.idtracker@ietfa.amsl.com> From: Klaus Hartke Date: Mon, 7 Oct 2013 18:32:55 +0300 Message-ID: To: Carsten Bormann Content-Type: text/plain; charset=ISO-8859-1 Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] draft-hartke-dice-practical-issues-00.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 15:33:48 -0000 Carsten Bormann wrote: > Nice draft. > > A couple of quick comments: Feedback before I had the chance to forward the announcement to the mailing list -- *like*. The draft is an update of draft-hartke-core-codtls-02 with a few small additions and a new section that compares alternative strategies for DTLS handshake reliability. What I'd be interested in now is if other implementers share the assessment or if it's just me. > [DCOSS12] does *not* use GHC, instead they invent a header compression format not unlike the one in the draft (which fits into the RFC 6282 NHC scheme just like GHC does). Fixed in the next revision, thanks. > GHC happens to outperform the DCOSS12 scheme in many cases, because it looks at the whole packet, so it also compresses the cipher suite specific header. Any attempt to get good compression should make use of this somewhat surprising result. Do you have some numbers that I could add to the draft? Best regards, Klaus From cabo@tzi.org Mon Oct 7 09:03:44 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D602921E81D5 for ; Mon, 7 Oct 2013 09:03:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1hGFIENAe9D0 for ; Mon, 7 Oct 2013 09:03:33 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4097221E81C5 for ; Mon, 7 Oct 2013 09:03:32 -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.4/8.14.4) with ESMTP id r97G3TQM029469 for ; Mon, 7 Oct 2013 18:03:29 +0200 (CEST) Received: from pptp-218-1.informatik.uni-bremen.de (pptp-218-1.informatik.uni-bremen.de [134.102.218.240]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id B1A8E3D9; Mon, 7 Oct 2013 18:03:29 +0200 (CEST) Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) Content-Type: text/plain; charset=iso-8859-1 From: Carsten Bormann In-Reply-To: Date: Mon, 7 Oct 2013 18:03:28 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <58476F92-05E7-4562-B2E0-AE812B27A163@tzi.org> References: <20131007144053.16131.80399.idtracker@ietfa.amsl.com> To: Klaus Hartke X-Mailer: Apple Mail (2.1510) Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] draft-hartke-dice-practical-issues-00.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 07 Oct 2013 16:03:45 -0000 On Oct 7, 2013, at 17:32, Klaus Hartke wrote: > Do you have some numbers that I could add to the draft? Results for Lithe (the new name of the [DCOSS12] scheme) are in: = http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=3D&arnumber=3D6576185= &queryText%3DLithe%3A+Lightweight+Secure+CoAP+for+the+Internet+of+Things (which is probably the paper you want to cite). Some numbers for GHC are in the GHC draft. These numbers aren't fully comparable yet, somebody has to do that work = (hint, hint). Gr=FC=DFe, Carsten From cabo@tzi.org Fri Oct 11 23:56:07 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 68DD021E80D0; Fri, 11 Oct 2013 23:56:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.861 X-Spam-Level: X-Spam-Status: No, score=-105.861 tagged_above=-999 required=5 tests=[AWL=-0.212, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_13=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WhMvb2eThU+5; Fri, 11 Oct 2013 23:55:56 -0700 (PDT) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7114821F9FA5; Fri, 11 Oct 2013 23:55:52 -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.4/8.14.4) with ESMTP id r9C6tjQc003442; Sat, 12 Oct 2013 08:55:45 +0200 (CEST) Received: from [192.168.217.105] (p54890CAC.dip0.t-ipconnect.de [84.137.12.172]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 87EA4D2E; Sat, 12 Oct 2013 08:55:44 +0200 (CEST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Carsten Bormann In-Reply-To: Date: Sat, 12 Oct 2013 08:55:43 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8529DF4C-1952-4A98-A4FC-B29806FE02B4@tzi.org> References: To: lwip@ietf.org, "core@ietf.org WG" , roll WG , 6lowpan@ietf.org, dtls-iot@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, "6tisch@ietf.org" <6tisch@ietf.org> X-Mailer: Apple Mail (2.1510) Subject: [Dtls-iot] Constrained Node/Network Cluster @ IETF88, "final" version X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 12 Oct 2013 06:56:07 -0000 On Oct 5, 2013, at 18:31, Carsten Bormann wrote: > A first draft version of the IETF88 agenda is out. [...] > Here is my usual eclectic condensed agenda built from that. =20 > All times are PST (UTC-0800). And here is the update based on the "final" agenda. (Which is "final" only in that it will be committed to print; it still = could change some more.) Apart from room changes, the changes are: 1) The lwig/6tisch conflict was resolved; unfortunately the moved lwig = now conflicts with perpass. 2) There will be no ROLL meeting in Vancouver. Besides the official agenda, there will be unofficial ("hallway") = meetings. I have started to collect info on a Wiki page: http://trac.tools.ietf.org/wg/core/trac/wiki/hallway88 You can edit and add meetings there using your tools login. Gr=FC=DFe, Carsten MONDAY, November 4, 2013 0900-1130 Morning Session I Georgia B APP appsawg Applications Area Working Group WG - - = Combined with APPAREA Regency D INT 6man IPv6 Maintenance WG 1300-1430 Afternoon Session I Regency B SEC *** dice DTLS In Constrained Environments WG 1450-1720 Afternoon Session II Georgia B APP *** core Constrained RESTful Environments WG Regency C INT intarea Internet Area Working Group WG Plaza C SEC oauth Web Authorization Protocol WG 1740-1940 Afternoon Session III Regency A APP httpbis Hypertext Transfer Protocol Bis WG Regency D OPS v6ops IPv6 Operations WG Regency C RTG rtgarea Routing Area Open Meeting TUESDAY, November 5, 2013 0900-1130 Morning Session I Georgia A APP httpbis Hypertext Transfer Protocol Bis WG 1300-1400 Afternoon Session I Plaza A APP json JavaScript Object Notation WG Regency B INT its Intelligent Transportation Systems BOF 1420-1550 Afternoon Session II Georgia B INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Regency B TSV tsvwg Transport Area Working Group WG 1610-1840 Afternoon Session III Regency A INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Plaza A OPS eman Energy Management WG Georgia A SEC tls Transport Layer Security WG WEDNESDAY, November 6, 2013 1300-1530 Afternoon Session I Plaza C INT *** lwig Light-Weight Implementation Guidance WG Regency C OPS v6ops IPv6 Operations WG Regency D SEC perpass Handling Pervasive Monitoring in the = IETF BOF Georgia B TSV rmcat RTP Media Congestion Avoidance = Techniques WG THURSDAY, November 7, 2013 0900-1130 Morning Session I Regency D INT homenet Home Networking WG Georgia A SEC jose Javascript Object Signing and Encryption = WG Regency C TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Regency D SEC saag Security Area Open Meeting 1520-1720 Afternoon Session II Regency B APP *** core Constrained RESTful Environments WG FRIDAY, November 8, 2013 0900-1100 Morning Session I Georgia B SEC httpauth Hypertext Transfer Protocol = Authentication WG Regency B TSV tsvwg Transport Area Working Group WG 1120-1220 Afternoon Session I Regency D INT dnssdext Extensions for Scalable DNS = Service Discovery WG 1230-1330 Afternoon Session II Regency D INT dnssdext Extensions for Scalable DNS = Service Discovery WG From sandeep.kumar@philips.com Thu Oct 17 05:27:35 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AE1821F9C20 for ; Thu, 17 Oct 2013 05:27:35 -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=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WTyMJ3yJHo2A for ; Thu, 17 Oct 2013 05:27:29 -0700 (PDT) Received: from db9outboundpool.messaging.microsoft.com (mail-db9lp0252.outbound.messaging.microsoft.com [213.199.154.252]) by ietfa.amsl.com (Postfix) with ESMTP id 515E221F9C46 for ; Thu, 17 Oct 2013 05:27:29 -0700 (PDT) Received: from mail122-db9-R.bigfish.com (10.174.16.236) by DB9EHSOBE021.bigfish.com (10.174.14.84) with Microsoft SMTP Server id 14.1.225.22; Thu, 17 Oct 2013 12:27:28 +0000 Received: from mail122-db9 (localhost [127.0.0.1]) by mail122-db9-R.bigfish.com (Postfix) with ESMTP id 71C1E300508 for ; Thu, 17 Oct 2013 12:27:28 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(zz217bI15d6O9371I936eI1be0I542I9251Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail122-db9 (localhost.localdomain [127.0.0.1]) by mail122-db9 (MessageSwitch) id 1382012846776785_26906; Thu, 17 Oct 2013 12:27:26 +0000 (UTC) Received: from DB9EHSMHS018.bigfish.com (unknown [10.174.16.253]) by mail122-db9.bigfish.com (Postfix) with ESMTP id B9C3742004B for ; Thu, 17 Oct 2013 12:27:26 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by DB9EHSMHS018.bigfish.com (10.174.14.28) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 17 Oct 2013 12:27:26 +0000 Received: from 011-DB3MMR1-018.MGDPHG.emi.philips.com (10.128.28.104) by 011-DB3MMR1-002.MGDPHG.emi.philips.com (10.128.28.52) with Microsoft SMTP Server (TLS) id 14.3.146.2; Thu, 17 Oct 2013 12:27:26 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.240]) by 011-DB3MMR1-018.MGDPHG.emi.philips.com ([10.128.28.104]) with mapi id 14.03.0146.002; Thu, 17 Oct 2013 12:27:14 +0000 From: "Kumar, Sandeep" To: "dtls-iot@ietf.org" Thread-Topic: New Version Notification for draft-keoh-dice-multicast-security-00.txt Thread-Index: AQHOyzK7gLwX5fqC70qgh+q2JVlWKJn40T5w Date: Thu, 17 Oct 2013 12:27:13 +0000 Message-ID: References: <20131017121631.21823.53284.idtracker@ietfa.amsl.com> In-Reply-To: <20131017121631.21823.53284.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-00.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 12:27:35 -0000 RGVhciBhbGwNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgbXVsdGljYXN0IHNlY3VyaXR5IHdpdGgg RFRMUyByZWNvcmQgbGF5ZXIgaXMgc3VibWl0dGVkLiBJdCBnaXZlcyBtb3JlIGRldGFpbHMgYW5k IHNvbWUgY29ycmVjdGlvbnMgdG8gdGhlIHByZXZpb3VzIHZlcnNpb24uDQoNCkxvb2tpbmcgZm9y d2FyZCB0byByZXZpZXdzIGFuZCBjb21tZW50cy4NCg0KS2luZCByZWdhcmRzDQpTYW5kZWVwDQoN Ci0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5v cmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmddDQpTZW50OiBUaHVyc2RheSwgT2N0 b2JlciAxNywgMjAxMyAyOjE3IFBNDQpUbzogS3VtYXIsIFNhbmRlZXA7IFN5ZSBMb29uZyBLZW9o OyBLdW1hciwgU2FuZGVlcDsgR2FyY2lhIE1vcmNob24sIE9zY2FyOyBEaWprLCBFc2tvDQpTdWJq ZWN0OiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtlb2gtZGljZS1tdWx0aWNh c3Qtc2VjdXJpdHktMDAudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWtlb2gt ZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDAudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3Vi bWl0dGVkIGJ5IFN5ZSBMb29uZyBLZW9oIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9y eS4NCg0KRmlsZW5hbWU6ICAgICAgICBkcmFmdC1rZW9oLWRpY2UtbXVsdGljYXN0LXNlY3VyaXR5 DQpSZXZpc2lvbjogICAgICAgIDAwDQpUaXRsZTogICAgICAgICAgIERUTFMtYmFzZWQgTXVsdGlj YXN0IFNlY3VyaXR5IGZvciBMb3ctUG93ZXIgYW5kIExvc3N5IE5ldHdvcmtzIChMTE5zKQ0KQ3Jl YXRpb24gZGF0ZTogICAyMDEzLTEwLTE3DQpHcm91cDogICAgICAgICAgIEluZGl2aWR1YWwgU3Vi bWlzc2lvbg0KTnVtYmVyIG9mIHBhZ2VzOiAxNw0KVVJMOiAgICAgICAgICAgICBodHRwOi8vd3d3 LmlldGYub3JnL2ludGVybmV0LWRyYWZ0cy9kcmFmdC1rZW9oLWRpY2UtbXVsdGljYXN0LXNlY3Vy aXR5LTAwLnR4dA0KU3RhdHVzOiAgICAgICAgICBodHRwOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv ZG9jL2RyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHkNCkh0bWxpemVkOiAgICAgICAg aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQta2VvaC1kaWNlLW11bHRpY2FzdC1zZWN1 cml0eS0wMA0KDQoNCkFic3RyYWN0Og0KICAgV2lyZWxlc3MgSVAtYmFzZWQgc3lzdGVtcyB3aWxs IGJlIGluY3JlYXNpbmdseSB1c2VkIGZvciBidWlsZGluZw0KICAgY29udHJvbCBzeXN0ZW1zIGlu IHRoZSBmdXR1cmUgd2hlcmUgd2lyZWxlc3MgZGV2aWNlcyBpbnRlcmNvbm5lY3QNCiAgIHdpdGgg ZWFjaCBvdGhlciwgZm9ybWluZyBsb3ctcG93ZXIgYW5kIGxvc3N5IG5ldHdvcmtzIChMTE5zKS4g IFRoZQ0KICAgQ29BUC82TG9XUEFOIHN0YW5kYXJkcyBhcmUgZW1lcmdpbmcgYXMgdGhlIGRlLWZh Y3RvIHByb3RvY29scyBpbiB0aGlzDQogICBhcmVhIGZvciByZXNvdXJjZS1jb25zdHJhaW5lZCBk ZXZpY2VzLiAgQm90aCBtdWx0aWNhc3QgYW5kIHNlY3VyaXR5DQogICBhcmUga2V5IG5lZWRzIGlu IHRoZXNlIG5ldHdvcmtzLiAgVGhpcyBkcmFmdCBwcmVzZW50cyBhIG1ldGhvZCBmb3INCiAgIHNl Y3VyaW5nIG11bHRpY2FzdCBjb21tdW5pY2F0aW9uIGluIExMTnMgYmFzZWQgb24gdGhlIERUTFMg d2hpY2ggaXMNCiAgIGFscmVhZHkgYXZhaWxhYmxlIGluIENvQVAgZGV2aWNlcy4gIFRoaXMgZHJh ZnQgZGVhbHMgd2l0aCB0aGUNCiAgIGFkYXB0YXRpb24gb2YgdGhlIERUTFMgcmVjb3JkIGxheWVy IHRvIHByb3RlY3QgbXVsdGljYXN0IGdyb3VwDQogICBjb21tdW5pY2F0aW9uLCBhc3N1bWluZyB0 aGF0IGFsbCBncm91cCBtZW1iZXIgZGV2aWNlcyBhcmUgYWxyZWFkeQ0KICAgY29uZmlndXJlZCB3 aXRoIHRoZSBncm91cCBzZWN1cml0eSBhc3NvY2lhdGlvbi4gIFRoZSBEVExTIHJlY29yZA0KICAg bGF5ZXIgaW1wbGVtZW50YXRpb24gaXMgdXNlZCB0byBlbmNyeXB0IGFuZCBwcm92aWRlIGF1dGhl bnRpY2F0aW9uIHRvDQogICBtdWx0aWNhc3QgbWVzc2FnZXMgdXNpbmcgdGhlIGdyb3VwIGtleWlu ZyBtYXRlcmlhbCBiZWZvcmUgc2VuZGluZyB0aGUNCiAgIG1lc3NhZ2UgdmlhIElQIG11bHRpY2Fz dCB0byB0aGUgZ3JvdXAuDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBh IGNvdXBsZSBvZiBtaW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUg aHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3Jn Lg0KDQpUaGUgSUVURiBTZWNyZXRhcmlhdA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fDQpUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWVzc2FnZSBtYXkgYmUg Y29uZmlkZW50aWFsIGFuZCBsZWdhbGx5IHByb3RlY3RlZCB1bmRlciBhcHBsaWNhYmxlIGxhdy4g VGhlIG1lc3NhZ2UgaXMgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgYWRkcmVzc2VlKHMpLiBJZiB5 b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCB5b3UgYXJlIGhlcmVieSBub3RpZmll ZCB0aGF0IGFueSB1c2UsIGZvcndhcmRpbmcsIGRpc3NlbWluYXRpb24sIG9yIHJlcHJvZHVjdGlv biBvZiB0aGlzIG1lc3NhZ2UgaXMgc3RyaWN0bHkgcHJvaGliaXRlZCBhbmQgbWF5IGJlIHVubGF3 ZnVsLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBpZW50LCBwbGVhc2UgY29udGFj dCB0aGUgc2VuZGVyIGJ5IHJldHVybiBlLW1haWwgYW5kIGRlc3Ryb3kgYWxsIGNvcGllcyBvZiB0 aGUgb3JpZ2luYWwgbWVzc2FnZS4NCg== From foleyj@cisco.com Thu Oct 17 11:33:22 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8321811E82A4 for ; Thu, 17 Oct 2013 11:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sH0XivK3fnWW for ; Thu, 17 Oct 2013 11:33:17 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 5DE5111E82A3 for ; Thu, 17 Oct 2013 11:33:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2890; q=dns/txt; s=iport; t=1382034797; x=1383244397; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=JgNWgiJIyGNr4/kZU+eMzFYOWvP+ESvoetTbbMZQjv8=; b=nEss/IsGvsMiHyUZYvxhxvdTeS0IThdBKxtpK8BZ58CCdChoQsfyzR8B BNWLFTZVcOZNtaDF2TdDvVgELHDbVQw7gMrZvChXmh3tbePBI2rK6yVsk ozS7PUZGxsJ7CSOKxAIgMYaWf3u0qBbPZh8T4bvxopwn5G4yH7oWFItJo c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkUFADAtYFKtJV2b/2dsb2JhbABagwfAOxZ0gxcNPRYYAwIBAgFYCAEBiAKfM6FOjhmBVYQQA5gGhjiLTINAIIEtJA X-IronPort-AV: E=Sophos;i="4.93,516,1378857600"; d="scan'208";a="273510877" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-4.cisco.com with ESMTP; 17 Oct 2013 18:32:58 +0000 Received: from [10.82.237.194] (rtp-vpn5-1469.cisco.com [10.82.237.194]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9HIWwKP028697 for ; Thu, 17 Oct 2013 18:32:58 GMT Message-ID: <52602D5A.5010201@cisco.com> Date: Thu, 17 Oct 2013 14:32:58 -0400 From: John Foley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: dtls-iot@ietf.org X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00] X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 17 Oct 2013 18:33:22 -0000 Hello colleagues, I've reviewed your draft for DTLS-based multicast security for low-power and LLNs. Please give consideration to my comments for your draft. Section 1.1: It's been a while since I've done multicast work. This is a nit, but isn't the traditional term used for a device receiving multicast packets called a "Receiver"? Using the term "Listener" may confuse traditional IP multicast experts. Section 4.1.1: How can we trust this ChangeCipherSpec message? Since all the detail of the DTLS handshake, security association setup, group setup, etc. are omitted from this draft, how do we know this ChangeCipherSpec is valid? This appears to be an easy opportunity for a denial of service attack. Comparing to TLS, TLS handshake messages are hashed and validated (RFC 5246 section 7.4.9). Additionally, some handshake messages are digitally signed (RFC 5246 section 7.4.3). It seems we need much more detail in this draft regarding re-synchronizing the epoch and seq# using the ChangeCipherSpec message. Or, consider using the approach defined in [draft-mcgrew-aero-00], which eliminates the need to synchronize the seq#. Section 4.1.2: What's wrong with using the IP address as the sender ID? If the IP address is included in the MAC, this provides the equivalent level of security as using the Sender ID. The added benefit would be no need to reduce the size of the sequence number. Additionally, protocols such as IGMP and PIM will use the source IP address to route many-to-many multicast packets. Using the IP address as the sender ID in this draft may allow for better cohesion with the network management entities and provide for more intelligence in security products such as firewalls and intrusion prevention. Section 4.2.1: How does a listener join an existing multicast feed while not failing the anti-replay check? This new listener will not know which sequence numbers are valid unless there's some form of synchronization logic, which doesn't appear to be defined in the draft. You may want to look at incorporating [draft-mcgrew-aero-00]. This allows for anti-replay protection while not needing to maintain state on the receiver side. AERO solves the problem of synchronizing the sequence number for late multicast joiners. This reduces the code footprint and complexity, which may be very beneficial for constrained devices. General comment: You may consider adding a section regarding IGMP and PIM. Should the reader assume there are no ramifications to IGMP/PIM? Any entity could join the multicast group and receive packets, albeit they will not be able to decrypt them. Or, is this protocol intended to only be used on local subnets? My point is maybe you should provide some context with respect to how multicast networks are typically deployed. Best regards, John Foley From sandeep.kumar@philips.com Fri Oct 18 07:30:39 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D08C011E81CD for ; Fri, 18 Oct 2013 07:30:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.849 X-Spam-Level: X-Spam-Status: No, score=-4.849 tagged_above=-999 required=5 tests=[AWL=1.750, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d7OFapkuDf-S for ; Fri, 18 Oct 2013 07:30:34 -0700 (PDT) Received: from va3outboundpool.messaging.microsoft.com (va3ehsobe006.messaging.microsoft.com [216.32.180.16]) by ietfa.amsl.com (Postfix) with ESMTP id BD45211E81D9 for ; Fri, 18 Oct 2013 07:30:33 -0700 (PDT) Received: from mail56-va3-R.bigfish.com (10.7.14.241) by VA3EHSOBE004.bigfish.com (10.7.40.24) with Microsoft SMTP Server id 14.1.225.22; Fri, 18 Oct 2013 14:30:32 +0000 Received: from mail56-va3 (localhost [127.0.0.1]) by mail56-va3-R.bigfish.com (Postfix) with ESMTP id 01825A00A3; Fri, 18 Oct 2013 14:30:33 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz217bI15d6O9371I1be0I542I1432I9251I1447Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dc1h1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail56-va3 (localhost.localdomain [127.0.0.1]) by mail56-va3 (MessageSwitch) id 1382106630728244_6814; Fri, 18 Oct 2013 14:30:30 +0000 (UTC) Received: from VA3EHSMHS028.bigfish.com (unknown [10.7.14.238]) by mail56-va3.bigfish.com (Postfix) with ESMTP id AD23012003F; Fri, 18 Oct 2013 14:30:30 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by VA3EHSMHS028.bigfish.com (10.7.99.38) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 18 Oct 2013 14:30:30 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.240]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.03.0146.002; Fri, 18 Oct 2013 14:30:29 +0000 From: "Kumar, Sandeep" To: John Foley , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00] Thread-Index: Ac7MDpccOgAUTB3gTYiobjrtW2HMYQ== Date: Fri, 18 Oct 2013 14:30:29 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Nancy Cam-Winget , "Dijk, Esko" , David McGrew , "SyeLoong.Keoh@glasgow.ac.uk" , "Garcia Morchon, Oscar" Subject: Re: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00] X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 14:30:39 -0000 Dear John Thanks for the detailed and helpful review. Please find below our reply. Kind regards Sandeep > -----Original Message----- > From: dtls-iot-bounces@ietf.org [mailto:dtls-iot-bounces@ietf.org] On > Behalf Of John Foley > Sent: Thursday, October 17, 2013 8:33 PM > To: dtls-iot@ietf.org > Subject: [Dtls-iot] Comments on > [draft-keoh-dice-multicast-security-00] > > Hello colleagues, > > I've reviewed your draft for DTLS-based multicast security for > low-power and LLNs. Please give consideration to my comments for your dr= aft. > > Section 1.1: It's been a while since I've done multicast work. This > is a nit, but isn't the traditional term used for a device receiving > multicast packets called a "Receiver"? Using the term "Listener" may > confuse traditional IP multicast experts. [SK]"Listener" is the term used in MLDv2 for IPv6 (RFC3810). But agree that= most multicast security related RFC refer to them as receivers. We will change the terminology to = what you suggest in the next version to be consistent with security folks. > > Section 4.1.1: How can we trust this ChangeCipherSpec message? Since > all the detail of the DTLS handshake, security association setup, > group setup, etc. are omitted from this draft, how do we know this > ChangeCipherSpec is valid? This appears to be an easy opportunity for a = denial of service attack. > Comparing to TLS, TLS handshake messages are hashed and validated (RFC > 5246 section 7.4.9). Additionally, some handshake messages are > digitally signed (RFC 5246 section 7.4.3). It seems we need much more > detail in this draft regarding re-synchronizing the epoch and seq# > using the ChangeCipherSpec message. Or, consider using the approach > defined in [draft-mcgrew-aero-00], which eliminates the need to synchroni= ze the seq#. [SK] You are right, the ChangeCipherSpec or any mechanism to update epoch (= when the sequence number wraps) should be secured. Since DICE is not chartered at this point to desi= gn any key management for the multicast security, it would be better to remove any reference to ChangeCip= herSpec and leave such mechanisms to a future specification of secure key management. It is likel= y that the scope of DICE will be extended to look at these issues in the future. .AERO looks like a good primitive to use in this scenario, but not clear ho= w this would solve the epoch update needed in DTLS after the seq number wrap around. > > Section 4.1.2: What's wrong with using the IP address as the sender > ID? If the IP address is included in the MAC, this provides the > equivalent level of security as using the Sender ID. The added > benefit would be no need to reduce the size of the sequence number. > Additionally, protocols such as IGMP and PIM will use the source IP > address to route many-to-many multicast packets. Using the IP address > as the sender ID in this draft may allow for better cohesion with the > network management entities and provide for more intelligence in > security products such as firewalls and intrusion prevention. [SK] Indeed, the IP address would have been a right candidate as SenderID t= o MAC. However (D)TLS is at a different layer in the network stack and it does not allow using headers = from the lower layer (IP) to be used in the associated data. This would require a change to (D)TLS itself.= However, the main reason to partition the sequence number space according to the sender is to avoid seq= uence number re-use. In the AES-CCM mode of operation, it is crucial to ensure that a particular sequen= ce number is not re-used. By adopting the method you proposed, multiple senders may use the same sequenc= e number, and the same group key to encrypt different messages, thus vulnerable to security attack= s. AERO may not have this problem if the IP address is part of the associated data, but we try to keep this g= eneral to any ciphersuite. > > Section 4.2.1: How does a listener join an existing multicast feed > while not failing the anti-replay check? This new listener will not > know which sequence numbers are valid unless there's some form of > synchronization logic, which doesn't appear to be defined in the draft. > You may want to look at incorporating [draft-mcgrew-aero-00]. This > allows for anti-replay protection while not needing to maintain state > on the receiver side. AERO solves the problem of synchronizing the > sequence number for late multicast joiners. This reduces the code > footprint and complexity, which may be very beneficial for constrained de= vices. > [SK] Late joiners are something we have not considered yet. The solution is= AERO with one dropped packet would be nice to have in this case. We will try to incorporate this hopeful= ly without too many changes to the DTLS record layer processing. And of course, we welcome contribution (e.g.,= co-authorship) from Cisco to further improve this draft together. > General comment: You may consider adding a section regarding IGMP and > PIM. Should the reader assume there are no ramifications to IGMP/PIM? > Any entity could join the multicast group and receive packets, albeit > they will not be able to decrypt them. Or, is this protocol intended > to only be used on local subnets? My point is maybe you should > provide some context with respect to how multicast networks are typically= deployed. [SK] We will provide more details on the IP multicast itself and make clear= that we intend to target IPv6 and 6lowPAN networks only. We expect that this draft does not affect or neither= influences how MLDv2 or any multicast routing protocol works. This would be similar to how RFC5374 appr= oaches with IPSec. Our target is to only ensure that data payload in such a multicast communication can b= e secured. So if an entity joins the multicast group and receive packets, albeit they will not be able to de= crypt them if they do not have the right key material. > > Best regards, > John Foley > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot ________________________________ 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. From Rene.Hummen@comsys.rwth-aachen.de Fri Oct 18 10:17:09 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 766E311E8328 for ; Fri, 18 Oct 2013 10:17:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hZiOvL1qUi19 for ; Fri, 18 Oct 2013 10:17:04 -0700 (PDT) Received: from mx-out-1.rwth-aachen.de (mx-out-1.rwth-aachen.de [134.130.5.186]) by ietfa.amsl.com (Postfix) with ESMTP id 9F59411E8316 for ; Fri, 18 Oct 2013 10:17:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.93,523,1378850400"; d="p7s'?scan'208";a="242296147" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-1.rz.rwth-aachen.de with ESMTP; 18 Oct 2013 19:17:02 +0200 Received: from messenger.nets.rwth-aachen.de (messenger.nets.rwth-aachen.de [137.226.13.40]) by mail-i4.nets.rwth-aachen.de (Postfix) with ESMTP id ADB8513DBFB for ; Fri, 18 Oct 2013 19:17:01 +0200 (CEST) Received: from MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee]) by MESSENGER.nets.rwth-aachen.de ([fe80::d4e:bb9d:9e0:bfee%12]) with mapi; Fri, 18 Oct 2013 19:17:01 +0200 From: Rene Hummen To: "dtls-iot@ietf.org" Thread-Topic: New Version Notification for draft-hummen-dtls-extended-session-resumption-01.txt Thread-Index: AQHOzBwDmO3KCq/R9kub4igIOZzBwg== Date: Fri, 18 Oct 2013 17:17:01 +0000 Message-ID: References: <20131018160554.4122.6390.idtracker@ietfa.amsl.com> Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Content-Type: multipart/signed; boundary="Apple-Mail=_216609C0-E0D3-488C-9167-C6BA777ADDAE"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Subject: [Dtls-iot] Fwd: New Version Notification for draft-hummen-dtls-extended-session-resumption-01.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 18 Oct 2013 17:17:09 -0000 --Apple-Mail=_216609C0-E0D3-488C-9167-C6BA777ADDAE Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Dear all, we have updated our draft on extended session resumption mechanisms for = DTLS. The main focus of this draft is to reduce the computation and = transmission overhead for constrained clients or servers if a DTLS = session cannot be kept open indefinitely. In this updated version, we added three descriptions of possible usage = scenarios, where we believe session resumption to be highly beneficial. = Furthermore, we added a section on how minimal session tickets could be = structured. While this draft may not fully satisfy the current scope of DICE, we = would be glad to receive feedback regarding the described (and maybe = additional) usage scenarios. After getting feedback from people in this = WG (with focus on constrained network environments), we then plan to = propose our DTLS protocol extension in the DTLS WG. BR Ren=E9 Hummen Begin forwarded message: > From: > Subject: New Version Notification for = draft-hummen-dtls-extended-session-resumption-01.txt > Date: October 18, 2013 6:05:54 PM GMT+02:00 > To: Hossein Shafagh , Rene Hummen = , Johannes Gilger = >=20 >=20 > A new version of I-D, = draft-hummen-dtls-extended-session-resumption-01.txt > has been successfully submitted by Rene Hummen and posted to the > IETF repository. >=20 > Filename: draft-hummen-dtls-extended-session-resumption > Revision: 01 > Title: Extended DTLS Session Resumption for = Constrained Network Environments > Creation date: 2013-10-18 > Group: Individual Submission > Number of pages: 14 > URL: = http://www.ietf.org/internet-drafts/draft-hummen-dtls-extended-session-res= umption-01.txt > Status: = http://datatracker.ietf.org/doc/draft-hummen-dtls-extended-session-resumpt= ion > Htmlized: = http://tools.ietf.org/html/draft-hummen-dtls-extended-session-resumption-0= 1 > Diff: = http://www.ietf.org/rfcdiff?url2=3Ddraft-hummen-dtls-extended-session-resu= mption-01 >=20 > Abstract: > This draft defines two extensions for the existing session = resumption > mechanisms of TLS that specifically apply to Datagram TLS (DTLS) in > constrained network environments. Session resumption type > negotiation enables the client and the server to explicitly agree on > the session resumption mechanism for subsequent handshakes, thus > avoiding unnecessary overheads occurring with the existing > specifications. Session resumption without client-side state > additionally enables a constrained DTLS client to resume a session > without the need to maintain state while the session is inactive. > The extensions defined in this draft update [RFC5077] and [RFC5246]. >=20 >=20 >=20 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > The IETF Secretariat >=20 -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21465 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_216609C0-E0D3-488C-9167-C6BA777ADDAE Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIOGzCCBCEw ggMJoAMCAQICAgDHMA0GCSqGSIb3DQEBBQUAMHExCzAJBgNVBAYTAkRFMRwwGgYDVQQKExNEZXV0 c2NoZSBUZWxla29tIEFHMR8wHQYDVQQLExZULVRlbGVTZWMgVHJ1c3QgQ2VudGVyMSMwIQYDVQQD ExpEZXV0c2NoZSBUZWxla29tIFJvb3QgQ0EgMjAeFw0wNjEyMTkxMDI5MDBaFw0xOTA2MzAyMzU5 MDBaMFoxCzAJBgNVBAYTAkRFMRMwEQYDVQQKEwpERk4tVmVyZWluMRAwDgYDVQQLEwdERk4tUEtJ MSQwIgYDVQQDExtERk4tVmVyZWluIFBDQSBHbG9iYWwgLSBHMDEwggEiMA0GCSqGSIb3DQEBAQUA A4IBDwAwggEKAoIBAQDpm8NnhfkNrvWNVMOWUDU9YuluTO2U1wBblSJ01CDrNI/W7MAxBAuZgeKm FNJSoCgjhIt0iQReW+DieMF4yxbLKDU5ey2QRdDtoAB6fL9KDhsAw4bpXCsxEXsM84IkQ4wcOItq aACa7txPeKvSxhObdq3u3ibo7wGvdA/BCaL2a869080UME/15eOkyGKbghoDJzANAmVgTe3RCSMq ljVYJ9N2xnG2kB3E7f81hn1vM7PbD8URwoqDoZRdQWvY0hD1TP3KUazZve+Sg7va64sWVlZDz+HV Ez2mHycwzUlU28kTNJpxdcVs6qcLmPkhnSevPqM5OUhqjK3JmfvDEvK9AgMBAAGjgdkwgdYwcAYD VR0fBGkwZzBloGOgYYZfaHR0cDovL3BraS50ZWxlc2VjLmRlL2NnaS1iaW4vc2VydmljZS9hZl9E b3dubG9hZEFSTC5jcmw/LWNybF9mb3JtYXQ9WF81MDkmLWlzc3Vlcj1EVF9ST09UX0NBXzIwHQYD VR0OBBYEFEm3xs/oPR9/6kR7Eyn38QpwPt5kMB8GA1UdIwQYMBaAFDHDeRu69VPXF+CJei0XbAqz K50zMA4GA1UdDwEB/wQEAwIBBjASBgNVHRMBAf8ECDAGAQH/AgECMA0GCSqGSIb3DQEBBQUAA4IB AQA74Vp3wEgX3KkY7IGvWonwvSiSpspZGBJw7Cjy565/lizn8l0ZMfYTK3S9vYCyufdnyTmieTvh ERHua3iRM347XyYndVNljjNj7s9zw7CSI0khUHUjoR8Y4pSFPT8z6XcgjaK95qGFKUD2P3MyWA0J a6bahWzAP7uNZmRWJE6uDT8yNQFb6YyC2XJZT7GGhfF0hVblw/hc843uR7NTBXDn5U2KaYMo4RMJ hp5eyOpYHgwf+aTUWgRo/Sg+iwK2WLX2oSw3VwBnqyNojWOl75lrXP1LVvarQIc01BGSbOyHxQoL BzNytG8MHVQs2FHHzL8w00Ny8TK/jM5JY6gA9/IcMIIE6DCCA9CgAwIBAgIECfJ04DANBgkqhkiG 9w0BAQUFADBaMQswCQYDVQQGEwJERTETMBEGA1UEChMKREZOLVZlcmVpbjEQMA4GA1UECxMHREZO LVBLSTEkMCIGA1UEAxMbREZOLVZlcmVpbiBQQ0EgR2xvYmFsIC0gRzAxMB4XDTA3MDIxNDExNDkz OFoXDTE5MDIxMzAwMDAwMFowXjELMAkGA1UEBhMCREUxFDASBgNVBAoTC1JXVEggQWFjaGVuMRcw FQYDVQQDEw5SV1RIIEFhY2hlbiBDQTEgMB4GCSqGSIb3DQEJARYRY2FAcnd0aC1hYWNoZW4uZGUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQC4MAhk48jcelLfNUI5kvMv+CF54xJnL4x/ cJQnN2NId6CJ3fqs0siO2exIACfzdjxOUpQ6ZFOn5pdTvTi7stnk8WAaP/d9LFd8k9Gbxjh7xh3L +0a3ac+/tHJcX564ntUxGtVGMuShEoUaZUT5fw97TL36UJ8OqXLrqpdAKcFKaJ+pgRp2gTLj4MNU MPjA4GlstpjoLnT++qFm7t/ZS92/E3OqNJUwHH6C35vSroVscmg+a7XxT6U4JO99MYxNcTIMzhPS 9Ytp+302w7i51daBjr0hFGPK0nLSV6gv77zBSFJ7AVGJJxBSUzDn0xkDLYvZwqaeYkj8kDB2oSeR yfGjAgMBAAGjggGwMIIBrDAPBgNVHRMBAf8EBTADAQH/MAsGA1UdDwQEAwIBBjAdBgNVHQ4EFgQU btU+wBwvcck8v0lO72pVSOzR8jgwHwYDVR0jBBgwFoAUSbfGz+g9H3/qRHsTKffxCnA+3mQwHAYD VR0RBBUwE4ERY2FAcnd0aC1hYWNoZW4uZGUwgYgGA1UdHwSBgDB+MD2gO6A5hjdodHRwOi8vY2Rw MS5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMD2gO6A5hjdodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL2dsb2JhbC1yb290LWNhL3B1Yi9jcmwvY2FjcmwuY3JsMIGiBggr BgEFBQcBAQSBlTCBkjBHBggrBgEFBQcwAoY7aHR0cDovL2NkcDEucGNhLmRmbi5kZS9nbG9iYWwt cm9vdC1jYS9wdWIvY2FjZXJ0L2NhY2VydC5jcnQwRwYIKwYBBQUHMAKGO2h0dHA6Ly9jZHAyLnBj YS5kZm4uZGUvZ2xvYmFsLXJvb3QtY2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEB BQUAA4IBAQAXh37GLAscIHrVqQYrG5P/dYULxAseU6xuXKnSpVTnMWVFf1TtN/p2D+8XTKtl/A4W lYa9np+ONblWcS1nJsuYf7N9wrO4zCEcVBNLIAHCY3ZXG+IoNHwgXqSYqXHzrAQZjkSJr1RfbFE4 njUy0nNhtC51HX0ongWfqODc6z7aF9we20615Mh8Kk8uox4XgjLLV/UjPVlwRAnuYIeF0wycvQ6j z/PJMuOrXShpqejpaiRXqKx8oPXAlCcnoqRLlQc1L0iwQHBn0Em6tDmMHcahbf9SBOWiZ8+O0av4 ly8CQ95okz9hto9UErXUIzNea2AQXBtlIyLLKgVuYPf4i3IyMIIFBjCCA+6gAwIBAgIHFHkMp6Zz lDANBgkqhkiG9w0BAQUFADBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldUSCBBYWNoZW4xFzAV BgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3RoLWFhY2hlbi5kZTAe Fw0xMjA5MTkwOTIzMzVaFw0xNTA5MTkwOTIzMzVaMDkxCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEUMBIGA1UEAxMLUmVuZSBIdW1tZW4wggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAw ggEKAoIBAQDDoo52P1ghFxnZmWNVnv7+qDKjyif4AoLkJrs7CVV34cRm/PhuW8WzLqOES0B0ENWE eDUez2Dc4inRNXdF5zMy36rLuKsK5MuznnXTzqYGMeGQAU7MkUvSZdMIWDpMdVc5nKzP81leStBY c3t6T2PNFHbeQEoHqjUNMQc9wfFWVQHTnQt9+kejn8NDMHqzKjJ+bnXm3byZCEs09CnmGli1irfJ cR6Fo4KcRMHKVrAHUG8NB+QyPv9RzEawbxwZgyDot5G/A4iRnX0aZ7OjB6ohkepKniBZqSMeOIu1 /Y7p6zYwqiLLywX1VtDQz067R4pkrT5h/IO/VcEGXukXqPA/AgMBAAGjggHsMIIB6DAvBgNVHSAE KDAmMBEGDysGAQQBga0hgiwBAQQCAzARBg8rBgEEAYGtIYIsAgEEAgMwCQYDVR0TBAIwADALBgNV HQ8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMB0GA1UdDgQWBBTAJpMHhUGI 9hiu0k6Ccd8MggDivTAfBgNVHSMEGDAWgBRu1T7AHC9xyTy/SU7valVI7NHyODAsBgNVHREEJTAj gSFyZW5lLmh1bW1lbkBjb21zeXMucnd0aC1hYWNoZW4uZGUweQYDVR0fBHIwcDA2oDSgMoYwaHR0 cDovL2NkcDEucGNhLmRmbi5kZS9yd3RoLWNhL3B1Yi9jcmwvY2FjcmwuY3JsMDagNKAyhjBodHRw Oi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2NybC9jYWNybC5jcmwwgZQGCCsGAQUFBwEB BIGHMIGEMEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMS5wY2EuZGZuLmRlL3J3dGgtY2EvcHViL2Nh Y2VydC9jYWNlcnQuY3J0MEAGCCsGAQUFBzAChjRodHRwOi8vY2RwMi5wY2EuZGZuLmRlL3J3dGgt Y2EvcHViL2NhY2VydC9jYWNlcnQuY3J0MA0GCSqGSIb3DQEBBQUAA4IBAQCA/Plhm3Cxu6mOs3O3 Wsl/9Ow7rbANrMvB2zxZW4yGJGu5FKaib+ir66xbpMAbmN4gqQmwuDMW+oWC7U+m9IfFG+T482Rz AvsYEOZUmq3Y0KFx87MEJdgaWtJ7PnlUaGtgQjdMso0pvAboZnp2pfxazq46lHXDgTCJsd7MUHb6 MzV9JpDzq0qnXeM2d+WxpOckuo11SAtXod+zuI9Udm7oUVIGeI8yFQrtHhtfESOmi57zSTseEYNS meInQtPv1ARHwuFRBcG5SkHDqbFZIw+2QVK2qq23NlTeBB/JfitX13NYdYNMgymz30iHXvxmB1nN fmJ9RDejQ4SVonYR7pLLMYIC5zCCAuMCAQEwaTBeMQswCQYDVQQGEwJERTEUMBIGA1UEChMLUldU SCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcNAQkBFhFjYUByd3Ro LWFhY2hlbi5kZQIHFHkMp6ZzlDAJBgUrDgMCGgUAoIIBUzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcN AQcBMBwGCSqGSIb3DQEJBTEPFw0xMzEwMTgxNzE3MDFaMCMGCSqGSIb3DQEJBDEWBBT7RvxnWCCl JkHcVf+Fhxy3G38lgTB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQBSem1D5ViY 5IKrWOZrhBk2kUwSU11WhgABsEOnrUugU/7wIAfSDQkS2VfQdXWb7vq5DsihoEylzBZBVKgmWaSi WYn71YCmz/LiO1jvFhNSWVpEZ4WebAdiZVzK7A5q/gmo+LJvHD4C8RnFRMa3hV0SVQ5wACHQJbw3 Oo8P4ZbwyAUaZGVqmKjeFC+ReSAuxQIeHVN93ZWX789+21Wtc5t+DvyYHqoLatfUv0J+W+VoVSIX icfeqoS4lHOt4B0CTYMLnEmoA4YCUPke488GBTORTr8vJDl7UiOZJu6dX0Ddg4hA5aRyKwOyoh/D cZ3nc7miTW0VtbCnr4mv9uZiPU6lAAAAAAAA --Apple-Mail=_216609C0-E0D3-488C-9167-C6BA777ADDAE-- From foleyj@cisco.com Mon Oct 21 08:23:32 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACB8111E85B6 for ; Mon, 21 Oct 2013 08:23:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hbiw+6z3TZ7p for ; Mon, 21 Oct 2013 08:23:27 -0700 (PDT) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 07FB511E85A5 for ; Mon, 21 Oct 2013 08:23:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8035; q=dns/txt; s=iport; t=1382368996; x=1383578596; h=message-id:date:from:mime-version:to:cc:subject: references:in-reply-to:content-transfer-encoding; bh=aLkvKoTHzSA9il3Yt+akklaynYK/grsvOengJo4HiEs=; b=kxUUHXUBoBaME2Rj4np6XrzA/iBt81HwvKGKddGJsac8phTBSVfFQkQl JI75TTfPYMxpjsFuRy9qcL34PLFtkcwNYk0C4sxEOquA2/BNZ/mmLr5g7 Ux5sGpRwMV3fYMifMuMmkkFmWf37s1J+5fWUZEYTh/fTpqrlmA95sLeMI 0=; X-IronPort-AV: E=Sophos;i="4.93,539,1378857600"; d="scan'208";a="274612170" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-2.cisco.com with ESMTP; 21 Oct 2013 15:23:15 +0000 Received: from [64.102.54.158] (dhcp-64-102-54-158.cisco.com [64.102.54.158]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r9LFNEek027865; Mon, 21 Oct 2013 15:23:14 GMT Message-ID: <526546E2.2060506@cisco.com> Date: Mon, 21 Oct 2013 11:23:14 -0400 From: John Foley User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , "dtls-iot@ietf.org" References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: Nancy Cam-Winget , "Dijk, Esko" , David McGrew , "SyeLoong.Keoh@glasgow.ac.uk" , "Garcia Morchon, Oscar" Subject: Re: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00] X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 15:23:32 -0000 Hi Sandeep, Regarding the multicast terminology for "Listener" or "Receiver", you are correct. The IPv6 specs have changed the terminology. You may want to continue using the term "Listener". I apologize for the misdirection. Regarding your comments on reusing the sequence number while using CCM mode, I'm a confused between sequence number reuse, IV reuse, and how you plan to coordinate this among multiple multicast senders. Section 4.1.2 doesn't fully describe how the encryption context should be initialized (e.g. what value to use for the IV). My understanding is AEAD ciphers such as CCM/GCM must not reuse an IV. With unicast TLS/DTLS the IV is derived from the master secret. There are two encryption contexts created for both reading and writing. Therefore, there are two IV values used in the unicast session (client_write_iv/server_write_iv). Your comment about reusing the sequence number has confused me. With your draft, should the IV now be derived from the sequence number rather than the master secret? How do you prevent IV reuse when there are multiple senders using the same master secret value? Regards, John On 10/18/2013 10:30 AM, Kumar, Sandeep wrote: > Dear John > > Thanks for the detailed and helpful review. Please find below our reply. > > Kind regards > Sandeep > > >> -----Original Message----- >> From: dtls-iot-bounces@ietf.org [mailto:dtls-iot-bounces@ietf.org] On >> Behalf Of John Foley >> Sent: Thursday, October 17, 2013 8:33 PM >> To: dtls-iot@ietf.org >> Subject: [Dtls-iot] Comments on >> [draft-keoh-dice-multicast-security-00] >> >> Hello colleagues, >> >> I've reviewed your draft for DTLS-based multicast security for >> low-power and LLNs. Please give consideration to my comments for your draft. >> >> Section 1.1: It's been a while since I've done multicast work. This >> is a nit, but isn't the traditional term used for a device receiving >> multicast packets called a "Receiver"? Using the term "Listener" may >> confuse traditional IP multicast experts. > [SK]"Listener" is the term used in MLDv2 for IPv6 (RFC3810). But agree that most multicast security > related RFC refer to them as receivers. We will change the terminology to what you suggest in the > next version to be consistent with security folks. > >> Section 4.1.1: How can we trust this ChangeCipherSpec message? Since >> all the detail of the DTLS handshake, security association setup, >> group setup, etc. are omitted from this draft, how do we know this >> ChangeCipherSpec is valid? This appears to be an easy opportunity for a denial of service attack. >> Comparing to TLS, TLS handshake messages are hashed and validated (RFC >> 5246 section 7.4.9). Additionally, some handshake messages are >> digitally signed (RFC 5246 section 7.4.3). It seems we need much more >> detail in this draft regarding re-synchronizing the epoch and seq# >> using the ChangeCipherSpec message. Or, consider using the approach >> defined in [draft-mcgrew-aero-00], which eliminates the need to synchronize the seq#. > [SK] You are right, the ChangeCipherSpec or any mechanism to update epoch (when the sequence number > wraps) should be secured. Since DICE is not chartered at this point to design any key management for the > multicast security, it would be better to remove any reference to ChangeCipherSpec and leave such > mechanisms to a future specification of secure key management. It is likely that the scope of DICE will be > extended to look at these issues in the future. > .AERO looks like a good primitive to use in this scenario, but not clear how this would solve the epoch > update needed in DTLS after the seq number wrap around. > >> Section 4.1.2: What's wrong with using the IP address as the sender >> ID? If the IP address is included in the MAC, this provides the >> equivalent level of security as using the Sender ID. The added >> benefit would be no need to reduce the size of the sequence number. >> Additionally, protocols such as IGMP and PIM will use the source IP >> address to route many-to-many multicast packets. Using the IP address >> as the sender ID in this draft may allow for better cohesion with the >> network management entities and provide for more intelligence in >> security products such as firewalls and intrusion prevention. > [SK] Indeed, the IP address would have been a right candidate as SenderID to MAC. However (D)TLS is at > a different layer in the network stack and it does not allow using headers from the lower layer (IP) to be > used in the associated data. This would require a change to (D)TLS itself. However, the main reason to > partition the sequence number space according to the sender is to avoid sequence number re-use. In the > AES-CCM mode of operation, it is crucial to ensure that a particular sequence number is not re-used. By > adopting the method you proposed, multiple senders may use the same sequence number, and the same > group key to encrypt different messages, thus vulnerable to security attacks. AERO may not have this problem > if the IP address is part of the associated data, but we try to keep this general to any ciphersuite. > > >> Section 4.2.1: How does a listener join an existing multicast feed >> while not failing the anti-replay check? This new listener will not >> know which sequence numbers are valid unless there's some form of >> synchronization logic, which doesn't appear to be defined in the draft. >> You may want to look at incorporating [draft-mcgrew-aero-00]. This >> allows for anti-replay protection while not needing to maintain state >> on the receiver side. AERO solves the problem of synchronizing the >> sequence number for late multicast joiners. This reduces the code >> footprint and complexity, which may be very beneficial for constrained devices. >> > [SK] Late joiners are something we have not considered yet. The solution is AERO with one dropped packet > would be nice to have in this case. We will try to incorporate this hopefully without too many changes to the > DTLS record layer processing. And of course, we welcome contribution (e.g., co-authorship) from Cisco to > further improve this draft together. > >> General comment: You may consider adding a section regarding IGMP and >> PIM. Should the reader assume there are no ramifications to IGMP/PIM? >> Any entity could join the multicast group and receive packets, albeit >> they will not be able to decrypt them. Or, is this protocol intended >> to only be used on local subnets? My point is maybe you should >> provide some context with respect to how multicast networks are typically deployed. > [SK] We will provide more details on the IP multicast itself and make clear that we intend to target IPv6 and > 6lowPAN networks only. We expect that this draft does not affect or neither influences how MLDv2 or any > multicast routing protocol works. This would be similar to how RFC5374 approaches with IPSec. Our target > is to only ensure that data payload in such a multicast communication can be secured. So if an entity joins > the multicast group and receive packets, albeit they will not be able to decrypt them if they do not have > the right key material. > > >> Best regards, >> John Foley >> >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot > ________________________________ > 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. > > . > From sandeep.kumar@philips.com Mon Oct 21 12:48:32 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8714C11E8713 for ; Mon, 21 Oct 2013 12:48:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.432 X-Spam-Level: X-Spam-Status: No, score=-5.432 tagged_above=-999 required=5 tests=[AWL=1.167, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cdlw+J3tkrxl for ; Mon, 21 Oct 2013 12:48:11 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 11E9221E808A for ; Mon, 21 Oct 2013 12:44:35 -0700 (PDT) Received: from mail25-tx2-R.bigfish.com (10.9.14.248) by TX2EHSOBE004.bigfish.com (10.9.40.24) with Microsoft SMTP Server id 14.1.225.22; Mon, 21 Oct 2013 19:44:35 +0000 Received: from mail25-tx2 (localhost [127.0.0.1]) by mail25-tx2-R.bigfish.com (Postfix) with ESMTP id 7D432601DE for ; Mon, 21 Oct 2013 19:44:35 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zz217bI15d6O9371I936eI9251I14ffIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail25-tx2 (localhost.localdomain [127.0.0.1]) by mail25-tx2 (MessageSwitch) id 1382384673666173_22226; Mon, 21 Oct 2013 19:44:33 +0000 (UTC) Received: from TX2EHSMHS041.bigfish.com (unknown [10.9.14.235]) by mail25-tx2.bigfish.com (Postfix) with ESMTP id 923E022004D for ; Mon, 21 Oct 2013 19:44:33 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS041.bigfish.com (10.9.99.141) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 21 Oct 2013 19:44:33 +0000 Received: from 011-DB3MMR1-017.MGDPHG.emi.philips.com (10.128.28.102) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.3.146.2; Mon, 21 Oct 2013 19:44:31 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.240]) by 011-DB3MMR1-017.MGDPHG.emi.philips.com ([10.128.28.102]) with mapi id 14.03.0146.002; Mon, 21 Oct 2013 19:44:28 +0000 From: "Kumar, Sandeep" To: "dtls-iot@ietf.org" Thread-Topic: New Version Notification for draft-kumar-dice-dtls-relay-00.txt Thread-Index: AQHOzoRhttXGfzCLlU2i+18ciO2Xzpn/jcjC Date: Mon, 21 Oct 2013 19:44:27 +0000 Message-ID: References: <20131021173809.32521.75353.idtracker@ietfa.amsl.com> In-Reply-To: <20131021173809.32521.75353.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: [Dtls-iot] FW: New Version Notification for draft-kumar-dice-dtls-relay-00.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 21 Oct 2013 19:48:45 -0000 Hi all A new draft has been submitted which presents a DTLS Relay method useful fo= r 6lowPAN/CoAP networks. Comments and suggestions are welcome. regards Sandeep ________________________________________ From: internet-drafts@ietf.org [internet-drafts@ietf.org] Sent: Monday, October 21, 2013 7:38 PM To: Kumar, Sandeep; Sye Loong Keoh; Kumar, Sandeep; Garcia Morchon, Oscar Subject: New Version Notification for draft-kumar-dice-dtls-relay-00.txt A new version of I-D, draft-kumar-dice-dtls-relay-00.txt has been successfully submitted by Sandeep S. Kumar and posted to the IETF repository. Filename: draft-kumar-dice-dtls-relay Revision: 00 Title: DTLS Relay for Constrained Environments Creation date: 2013-10-21 Group: Individual Submission Number of pages: 11 URL: http://www.ietf.org/internet-drafts/draft-kumar-dice-dtls-= relay-00.txt Status: http://datatracker.ietf.org/doc/draft-kumar-dice-dtls-rela= y Htmlized: http://tools.ietf.org/html/draft-kumar-dice-dtls-relay-00 Abstract: The 6LoWPAN and CoAP standards defined for resource-constrained devices are fast emerging as the de-facto protocols for enabling the Internet-of-Things (IoTs). Security is an important concern in IoTs and the DTLS protocol has been chosen as the preferred method for securing CoAP messages. DTLS is a point-to-point protocol relying on the IP routing to deliver messages between the client and the server. However in some low-power lossy networks (LLNs) with multi-hop, a new "joining" device may not be initially IP routable. This prevents DTLS from being directly useful as an authentication and confidentiality protocol during this stage, requiring other security protocols to be implemented on the device. These devices being resource-constrained often cannot accommodate more than one security protocol in their code memory. To overcome this problem and reuse DTLS, we present a DTLS Relay solution for the non-IP routable "joining" device to establish a secure DTLS connection with a DTLS server. Further we present a stateful and stateless mode of operation for the DTLS Relay. Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat ________________________________ 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. From sandeep.kumar@philips.com Tue Oct 22 02:20:38 2013 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE54E11E8328 for ; Tue, 22 Oct 2013 02:20:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id krcsff8mf5ec for ; Tue, 22 Oct 2013 02:20:33 -0700 (PDT) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id 8A01011E8353 for ; Tue, 22 Oct 2013 02:20:30 -0700 (PDT) Received: from mail137-co9-R.bigfish.com (10.236.132.252) by CO9EHSOBE034.bigfish.com (10.236.130.97) with Microsoft SMTP Server id 14.1.225.22; Tue, 22 Oct 2013 09:20:30 +0000 Received: from mail137-co9 (localhost [127.0.0.1]) by mail137-co9-R.bigfish.com (Postfix) with ESMTP id 021C48031E; Tue, 22 Oct 2013 09:20:30 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -33 X-BigFish: VPS-33(zzbb2dI217bI98dI15d6O9371I1be0I542I1432I9251I1447Idd85kzz1f42h208ch1ee6h1de0h1fdah2073h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2dh2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h1155h) Received: from mail137-co9 (localhost.localdomain [127.0.0.1]) by mail137-co9 (MessageSwitch) id 1382433628183742_25529; Tue, 22 Oct 2013 09:20:28 +0000 (UTC) Received: from CO9EHSMHS023.bigfish.com (unknown [10.236.132.228]) by mail137-co9.bigfish.com (Postfix) with ESMTP id 1EA791A0071; Tue, 22 Oct 2013 09:20:28 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS023.bigfish.com (10.236.130.33) with Microsoft SMTP Server (TLS) id 14.16.227.3; Tue, 22 Oct 2013 09:20:26 +0000 Received: from 011-DB3MMR1-022.MGDPHG.emi.philips.com (10.128.28.105) by 011-DB3MMR1-011.MGDPHG.emi.philips.com (10.128.28.50) with Microsoft SMTP Server (TLS) id 14.3.146.2; Tue, 22 Oct 2013 09:20:02 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.240]) by 011-DB3MMR1-022.MGDPHG.emi.philips.com ([fe80::1113:17d7:70dc:6faa%11]) with mapi id 14.03.0146.002; Tue, 22 Oct 2013 09:19:50 +0000 From: "Kumar, Sandeep" To: John Foley , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00] Thread-Index: Ac7MDpccOgAUTB3gTYiobjrtW2HMYQCYt58AACMDWQA= Date: Tue, 22 Oct 2013 09:19:50 +0000 Message-ID: References: <526546E2.2060506@cisco.com> In-Reply-To: <526546E2.2060506@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Cc: Nancy Cam-Winget , "Dijk, Esko" , David McGrew , "SyeLoong.Keoh@glasgow.ac.uk" , "Garcia Morchon, Oscar" Subject: Re: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-00] X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Oct 2013 09:20:39 -0000 Hi John First the background reference ----- According to the RFC6655 (AES-CCM for TLS) Section 3, CCMNonce is a combin= ation of a salt value and the sequence number. struct { opaque salt[4]; opaque nonce_explicit[8]; } CCMNonce; The salt is the IV generated from the handshake - client_write_IV (when the= client is sending) or the server_write_IV (when the server is sending). Further it says that "The value of the nonce_explicit MUST be distinct for = each distinct invocation of the GCM encrypt function for any fixed key." When the nonce_explicit is equal to the sequence number, the CCMNonce will = have the structure below. struct { uint32 client_write_IV; // low order 32-bits uint64 seq_num; // TLS sequence number } CCMClientNonce. struct { uint32 server_write_IV; // low order 32-bits uint64 seq_num; // TLS sequence number } CCMServerNonce. In DTLS, the 64-bit sequence number is the 16-bit epoch concatenated with t= he 48-bit seq_num. ------ According to my understanding, it is important that the CCMNonce is distinc= t based on the distinctness of the nonce_explicit. Ofcourse the IVs need to= change if the 64-bit seq_num wraps, but that is when (D)TLS renegotiation = kicks in to generate new IVs and session keys. In our case we let all servers (senders) use the same server_write_IV and a= ll clients (listeners) use the same client_write_IV. The client_write_IV is= not important here since listeners never write. Since the exact procedure = on how this should happen is a key management issue, we only mention in Sec= 4 that it is either derived (by using the same random sent by the controll= er) or the controller directly sets these values in all servers and clients= . For the nonce_explicit to be distinct, we use the recommendation ins RFC52= 88 (AES-GCM for TLS) Sec 6.2, to make nonce_explicit =3D FixedDistinct || Variable. Since in DTLS, the nonce_explicit=3Depoch || sequence_number, we apply the= recommendation as follows nonce_explicit=3DVariable1 || FixedDistinct || Variable2. For the FixedDistinct we use the SenderID (2 bytes) which should be distinc= t for all senders. The Variable1 is the epoch and Variable2 is the "truncat= ed" sequence number (4 bytes). This is shown in Figure 4.3 of our draft. Th= is avoids the nonce_explicit reuse across senders. If the nonce_explicit wraps, which in in this situation means [epoch|| "tru= ncated" sequence number] wraps, then just as in original DTLS, a renegotiat= ion to freshen up the IVs and/or session keys are required as discussed in = Sec 4.1 of DTLS (RFC6347). This is again something to be aware when designi= ng the key management part. Hope this clears your doubts or if I am wrong please let me know. Kind regards Sandeep > -----Original Message----- > From: John Foley [mailto:foleyj@cisco.com] > Sent: Monday, October 21, 2013 5:23 PM > To: Kumar, Sandeep; dtls-iot@ietf.org > Cc: SyeLoong.Keoh@glasgow.ac.uk; Garcia Morchon, Oscar; Dijk, Esko; David > McGrew; Nancy Cam-Winget > Subject: Re: [Dtls-iot] Comments on [draft-keoh-dice-multicast-security-0= 0] > > Hi Sandeep, > > Regarding the multicast terminology for "Listener" or "Receiver", you are > correct. The IPv6 specs have changed the terminology. You may want to > continue using the term "Listener". I apologize for the misdirection. > > Regarding your comments on reusing the sequence number while using CCM > mode, I'm a confused between sequence number reuse, IV reuse, and how > you plan to coordinate this among multiple multicast senders. Section > 4.1.2 doesn't fully describe how the encryption context should be initial= ized > (e.g. what value to use for the IV). My understanding is AEAD ciphers su= ch as > CCM/GCM must not reuse an IV. With unicast TLS/DTLS the IV is derived > from the master secret. There are two encryption contexts created for bo= th > reading and writing. Therefore, there are two IV values used in the unic= ast > session (client_write_iv/server_write_iv). Your comment about reusing th= e > sequence number has confused me. With your draft, should the IV now be > derived from the sequence number rather than the master secret? How do > you prevent IV reuse when there are multiple senders using the same > master secret value? > > Regards, > John > > On 10/18/2013 10:30 AM, Kumar, Sandeep wrote: > > Dear John > > > > Thanks for the detailed and helpful review. Please find below our reply= . > > > > Kind regards > > Sandeep > > > > > >> -----Original Message----- > >> From: dtls-iot-bounces@ietf.org [mailto:dtls-iot-bounces@ietf.org] On > >> Behalf Of John Foley > >> Sent: Thursday, October 17, 2013 8:33 PM > >> To: dtls-iot@ietf.org > >> Subject: [Dtls-iot] Comments on > >> [draft-keoh-dice-multicast-security-00] > >> > >> Hello colleagues, > >> > >> I've reviewed your draft for DTLS-based multicast security for > >> low-power and LLNs. Please give consideration to my comments for your > draft. > >> > >> Section 1.1: It's been a while since I've done multicast work. This > >> is a nit, but isn't the traditional term used for a device receiving > >> multicast packets called a "Receiver"? Using the term "Listener" may > >> confuse traditional IP multicast experts. > > [SK]"Listener" is the term used in MLDv2 for IPv6 (RFC3810). But agree > > that most multicast security related RFC refer to them as receivers. > > We will change the terminology to what you suggest in the next version = to > be consistent with security folks. > > > >> Section 4.1.1: How can we trust this ChangeCipherSpec message? > >> Since all the detail of the DTLS handshake, security association > >> setup, group setup, etc. are omitted from this draft, how do we know > >> this ChangeCipherSpec is valid? This appears to be an easy opportunit= y > for a denial of service attack. > >> Comparing to TLS, TLS handshake messages are hashed and validated > >> (RFC > >> 5246 section 7.4.9). Additionally, some handshake messages are > >> digitally signed (RFC 5246 section 7.4.3). It seems we need much > >> more detail in this draft regarding re-synchronizing the epoch and > >> seq# using the ChangeCipherSpec message. Or, consider using the > >> approach defined in [draft-mcgrew-aero-00], which eliminates the need > to synchronize the seq#. > > [SK] You are right, the ChangeCipherSpec or any mechanism to update > > epoch (when the sequence number > > wraps) should be secured. Since DICE is not chartered at this point to > > design any key management for the multicast security, it would be > > better to remove any reference to ChangeCipherSpec and leave such > > mechanisms to a future specification of secure key management. It is l= ikely > that the scope of DICE will be extended to look at these issues in the fu= ture. > > .AERO looks like a good primitive to use in this scenario, but not > > clear how this would solve the epoch update needed in DTLS after the se= q > number wrap around. > > > >> Section 4.1.2: What's wrong with using the IP address as the sender > >> ID? If the IP address is included in the MAC, this provides the > >> equivalent level of security as using the Sender ID. The added > >> benefit would be no need to reduce the size of the sequence number. > >> Additionally, protocols such as IGMP and PIM will use the source IP > >> address to route many-to-many multicast packets. Using the IP > >> address as the sender ID in this draft may allow for better cohesion > >> with the network management entities and provide for more > >> intelligence in security products such as firewalls and intrusion prev= ention. > > [SK] Indeed, the IP address would have been a right candidate as > > SenderID to MAC. However (D)TLS is at a different layer in the network > > stack and it does not allow using headers from the lower layer (IP) to > > be used in the associated data. This would require a change to (D)TLS > > itself. However, the main reason to partition the sequence number > > space according to the sender is to avoid sequence number re-use. In > > the AES-CCM mode of operation, it is crucial to ensure that a > > particular sequence number is not re-used. By adopting the method you > proposed, multiple senders may use the same sequence number, and the > same group key to encrypt different messages, thus vulnerable to security > attacks. AERO may not have this problem if the IP address is part of the > associated data, but we try to keep this general to any ciphersuite. > > > > > >> Section 4.2.1: How does a listener join an existing multicast feed > >> while not failing the anti-replay check? This new listener will not > >> know which sequence numbers are valid unless there's some form of > >> synchronization logic, which doesn't appear to be defined in the draft= . > >> You may want to look at incorporating [draft-mcgrew-aero-00]. This > >> allows for anti-replay protection while not needing to maintain state > >> on the receiver side. AERO solves the problem of synchronizing the > >> sequence number for late multicast joiners. This reduces the code > >> footprint and complexity, which may be very beneficial for constrained > devices. > >> > > [SK] Late joiners are something we have not considered yet. The > > solution is AERO with one dropped packet would be nice to have in this > > case. We will try to incorporate this hopefully without too many > > changes to the DTLS record layer processing. And of course, we welcome > contribution (e.g., co-authorship) from Cisco to further improve this dra= ft > together. > > > >> General comment: You may consider adding a section regarding IGMP > >> and PIM. Should the reader assume there are no ramifications to > IGMP/PIM? > >> Any entity could join the multicast group and receive packets, albeit > >> they will not be able to decrypt them. Or, is this protocol intended > >> to only be used on local subnets? My point is maybe you should > >> provide some context with respect to how multicast networks are > typically deployed. > > [SK] We will provide more details on the IP multicast itself and make > > clear that we intend to target IPv6 and 6lowPAN networks only. We > > expect that this draft does not affect or neither influences how MLDv2 > > or any multicast routing protocol works. This would be similar to how > > RFC5374 approaches with IPSec. Our target is to only ensure that data > > payload in such a multicast communication can be secured. So if an enti= ty > joins the multicast group and receive packets, albeit they will not be ab= le to > decrypt them if they do not have the right key material. > > > > > >> Best regards, > >> John Foley > >> > >> _______________________________________________ > >> dtls-iot mailing list > >> dtls-iot@ietf.org > >> https://www.ietf.org/mailman/listinfo/dtls-iot > > ________________________________ > > The information contained in this message may be confidential and legal= ly > protected under applicable law. The message is intended solely for the > addressee(s). If you are not the intended recipient, you are hereby notif= ied > that any use, forwarding, dissemination, or reproduction of this message = is > 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. > > > > . > > ________________________________ 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.