From nobody Sat Mar 1 21:16:18 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14AA11A034B for ; Sat, 1 Mar 2014 21:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.099 X-Spam-Level: X-Spam-Status: No, score=0.099 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UX6nROgRnutH for ; Sat, 1 Mar 2014 21:16:14 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 089731A02DF for ; Sat, 1 Mar 2014 21:16:13 -0800 (PST) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Sun, 02 Mar 2014 05:16:10 +0000 Received: from usa-sjc-gw2.usa.Arm.com (10.72.50.52) by usa-sjc-gw1.usa.Arm.com (10.72.50.51) with Microsoft SMTP Server (TLS) id 8.3.298.1; Sat, 1 Mar 2014 21:16:14 -0800 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Sat, 1 Mar 2014 21:16:14 -0800 From: Zach Shelby To: "dtls-iot@ietf.org" Date: Sat, 1 Mar 2014 21:16:09 -0800 Thread-Topic: DICE Agenda Thread-Index: Ac811oeKYUCcsJAPQDOIFceEF/DFNg== Message-ID: <73C9ECC9-CAEE-4165-BB0E-FADDD915A173@arm.com> 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: 114030205161000302 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/R0jYUYk9cME2FgZDpOEBovk3e6Q Subject: [Dtls-iot] DICE Agenda X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 02 Mar 2014 05:16:17 -0000 The DICE agenda has been posted. As we have just an hour time slot we will = focus on progressing just our WG items. See you in London, Zach IETF-89 dice agenda Session 2014-03-03 1520-1620: Sovereign - dice chatroom Agenda Administration [Chairs] 1= 0 Minutes - Agenda bashing - Call for scribes - Milestone review DTLS Profile draft [Klaus Hartke, Hannes Tschofenig] 2= 0 Minutes draft-hartke-dice-profile-03 - progress document Multicast draft [Sandeep Kumar] 2= 0 Minutes draft-keoh-dice-multicast-security-05 - address mailing list issues Next Steps [Chairs] 1= 0 Minutes 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 nobody Mon Mar 3 02:51:33 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 703591A0E9C for ; Mon, 3 Mar 2014 02:51:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AbTLcuB_5eoo for ; Mon, 3 Mar 2014 02:51:20 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 909DB1A0E2E for ; Mon, 3 Mar 2014 02:51:19 -0800 (PST) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Mon, 03 Mar 2014 10:51:15 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Mon, 3 Mar 2014 02:51:20 -0800 From: Zach Shelby To: "dtls-iot@ietf.org" Date: Mon, 3 Mar 2014 02:51:20 -0800 Thread-Topic: draft-hartke-dice-profile-03 comments Thread-Index: Ac82zoK60FGO+8NVTXKcP4JF+lMR4Q== Message-ID: <7CBD7068-03A1-4587-93D4-39D58FC1715A@arm.com> 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: 114030310511600202 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/WMdD55nRgG943pFiXOKiuNf3ElA Subject: [Dtls-iot] draft-hartke-dice-profile-03 comments X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 10:51:23 -0000 Here is my initial review on the draft-hartke-dice-profile-03. Overall, I t= hink this is an excellent start. I can already see IoT developers cracking = down cold beer and enjoying this document, it is going to save people a lot= of time and misunderstanding about DTLS in this space. General comments - The text often refers to keying material being installed or updated via f= irmware update. Although that could be the case for some limited systems (o= r just for the purpose of bootstrapping), we are seeing key management and = more generally device management for IoT device security configuration. We = don't want to give implementers the impression that they should be hard-cod= ing security configurations in firmware, as that get unmanageable quickly. = We should probably talk about "software update or security management mecha= nisms". For example when this profile would be used for Lightweight M2M for= example, such security management is provided by that standard itself over= CoAP. - The draft talks about only specifying Client functionality, but then in r= eality there are quite a few implementation requirements on Servers too=85 Section 1 "is likely to be useful for IoT scenarios as well" - Is this maybe a little= too unsure. As DTLS is required already by several standards for IoT, it i= s safe to assume DTLS will be widely used for IoT. This document is meant t= o make it a lot easier to use, implement and interoperate. Section 2 Some possible text to help clarify Client and Server terminology here: "Note that "Client" and "Server" in this document refer to TLS roles, where= the Client initiates the TLS handshake. This does not restrict the interac= tion pattern of the protocols carried inside TLS as the record layer allows= bi-directional communication. In the case of CoAP the "Client" can act as = a CoAP Server or Client." Section 4 If the RFC4279 PSK identity and key length requirements are not applicable = to this profile, we probably need to define what are? Section 5 Regarding the question, the must implement cipher required by CoAP for DTLS= was chosen to align with device hardware (802.15.4 SoCs typically have AES= -CCM hardware engines) and other standards like SE2.0 that requires that ci= pher. It is probably out of scope for us to start changing that in DICE. Of= course that is only the must implement cipher suite, a DTLS implementation= can support others. Section 6 The EUI-64 is not a required by CoAP for use as the Authority Name, but is = used as an example of a stable endpoint identifier. So I would say: "For client certificates the identifier used in the SubjectAltName or in th= e CN is a stable endpoint identifier such as an EUI-64 [EUI64], as describe= d in Section 9.1.3.3 of [I-D.ietf-core-coap]." Section 10 Regarding PFS and the chosen cipher suite, we should again probably leave t= hat to CoRE as implementers of course can support other cipher suites. We c= ould e.g. require that Servers support the sheffer-tls-bcp recommended ciph= ers for interoperability with a Client that choses to use them? 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 nobody Mon Mar 10 12:09:59 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31DD91A04F1 for ; Mon, 10 Mar 2014 12:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bfR-7Vr-vVXV for ; Mon, 10 Mar 2014 12:09:54 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 6C5451A06D9 for ; Mon, 10 Mar 2014 12:09:51 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Mon, 10 Mar 2014 19:09:45 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Mon, 10 Mar 2014 12:09:51 -0700 From: Zach Shelby To: "saag@ietf.org" Date: Mon, 10 Mar 2014 12:09:40 -0700 Thread-Topic: DICE WG report Thread-Index: Ac88lE+uJLEY5yz5SIeePF+X2m8vCA== Message-ID: <8CD36D87-EFC0-4D59-BD9C-97599E48F24F@arm.com> 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: 114031019094502102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/dHKrICzOuBcyPS866_G8XvW2DBY Cc: "dtls-iot@ietf.org" Subject: [Dtls-iot] DICE WG report X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:09:55 -0000 DICE IETF-89 WG Meeting Summary (for SAAG) The DICE group had a compact (one hour), well-attended and productive meeti= ng last week. We had two presentations covering our main work items. Hannes Tschofenig presented an overview of draft-hartke-dice-profil= e-03, on which the authors received good feedback on the need to cover peer= -to-peer DTLS between constrained devices and some of the decisions that ne= ed to be made in the profile draft. We will be calling for WG adoption of t= his draft today. Sandeep Kumar presented the progress on draft-keoh-dice-multicast-s= ecurity-05, which is related to our multicast DTLS record later WG charter = item. Since Vancouver the WG has been debating on the appropriate scope of = this work item, and some have argued that source authentication and public-= keys are needed. In the meeting there was good agreement that draft-keoh-di= ce-multicast-security-05 is a reasonable solution for what we were chartere= d to do, and we should not try to add source authentication to the DTLS rec= ord layer. It was agreed to encourage a straw-man draft to be written explo= ring if an alternative approach would make sense doing this in CoAP includi= ng source authentication. This is not in our charter, but the draft is mean= t to help us determine how to proceed. Sandeep has agreed to work with othe= rs on that draft. Finally, Ekr mentioned the TLS 1.3 effort and the need for input fr= om DICE regarding DTLS 1.3 and IoT support. We're encouraging the WG to giv= e their feedback regarding DTLS 1.3, and Klaus Hartke is at least intereste= d to write that up as a draft. 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 nobody Mon Mar 10 12:21:49 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 953C01A04C5 for ; Mon, 10 Mar 2014 12:21:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y72JyaWJCHfk for ; Mon, 10 Mar 2014 12:21:39 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id 7B05A1A04A6 for ; Mon, 10 Mar 2014 12:21:39 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Mon, 10 Mar 2014 19:21:33 +0000 Received: from usa-sjc-gw2.usa.Arm.com (10.72.50.52) by usa-sjc-gw1.usa.Arm.com (10.72.50.51) with Microsoft SMTP Server (TLS) id 8.3.298.1; Mon, 10 Mar 2014 12:21:40 -0700 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Mon, 10 Mar 2014 12:21:40 -0700 From: Zach Shelby To: "dtls-iot@ietf.org" Date: Mon, 10 Mar 2014 12:21:29 -0700 Thread-Topic: Call for WG adoption of draft-hartke-dice-profile-03 Thread-Index: Ac88lfXBPtoWHZgcS1ePalYVLmv2FA== Message-ID: <88AF60D4-06AF-4223-867F-29AE789AA9DD@arm.com> 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: 114031019213300302 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/R_tVA5kLno7biQgbA8Sd_iVcoF0 Subject: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Mar 2014 19:21:47 -0000 The draft draft-hartke-dice-profile-03 has made progress on our DTLS Profil= e WG item, and had good consensus during our London meeting. This email is = a call for confirmation of that consensus. Please respond if you support t= he adoption of this document as the basis for this work item. If adopted the authors would of course need to take into account the feedba= ck received during the DICE meeting in London, and changes going forward. >From our charter: Dec 2013 - WG document for DTLS for Constrained Environments profile Which keeps us on track to deliver: May 2014 - DTLS for IoT profile specification submitted to the IESG for p= ublication as standards track 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 nobody Tue Mar 11 02:41:31 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 338D01A03F2 for ; Tue, 11 Mar 2014 02:41:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.959 X-Spam-Level: X-Spam-Status: No, score=-1.959 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, CN_BODY_35=0.339, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SdiUxD_S80TR for ; Tue, 11 Mar 2014 02:41:28 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E35491A03E8 for ; Tue, 11 Mar 2014 02:41:27 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BEL30642; Tue, 11 Mar 2014 09:41:21 +0000 (GMT) Received: from LHREML402-HUB.china.huawei.com (10.201.5.241) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Mar 2014 09:40:25 +0000 Received: from SZXEMA407-HUB.china.huawei.com (10.82.72.39) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 11 Mar 2014 09:41:09 +0000 Received: from SZXEMA501-MBS.china.huawei.com ([169.254.2.158]) by SZXEMA407-HUB.china.huawei.com ([10.82.72.39]) with mapi id 14.03.0158.001; Tue, 11 Mar 2014 17:41:02 +0800 From: Likepeng To: Zach Shelby , "dtls-iot@ietf.org" Thread-Topic: Call for WG adoption of draft-hartke-dice-profile-03 Thread-Index: Ac88lfXBPtoWHZgcS1ePalYVLmv2FAAd/n8g Date: Tue, 11 Mar 2014 09:41:01 +0000 Message-ID: <34966E97BE8AD64EAE9D3D6E4DEE36F252B020D1@SZXEMA501-MBS.china.huawei.com> References: <88AF60D4-06AF-4223-867F-29AE789AA9DD@arm.com> In-Reply-To: <88AF60D4-06AF-4223-867F-29AE789AA9DD@arm.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.66.167.122] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Vlxkiz36Vn8N-DW9AuCzVyDyzj8 Subject: Re: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 09:41:30 -0000 PiBQbGVhc2UgcmVzcG9uZCBpZiB5b3Ugc3VwcG9ydCB0aGUNCj4gYWRvcHRpb24gb2YgdGhpcyBk b2N1bWVudCBhcyB0aGUgYmFzaXMgZm9yIHRoaXMgd29yayBpdGVtLg0KDQorMS4NCg0KS2luZCBS ZWdhcmRzDQpLZXBlbmcNCg0KPiAtLS0tLdPKvP7Urbz+LS0tLS0NCj4gt6K8/sjLOiBkdGxzLWlv dCBbbWFpbHRvOmR0bHMtaW90LWJvdW5jZXNAaWV0Zi5vcmddILT6se0gWmFjaCBTaGVsYnkNCj4g t6LLzcqxvOQ6IDIwMTTE6jPUwjExyNUgMzoyMQ0KPiDK1bz+yMs6IGR0bHMtaW90QGlldGYub3Jn DQo+INb3zOI6IFtEdGxzLWlvdF0gQ2FsbCBmb3IgV0cgYWRvcHRpb24gb2YgZHJhZnQtaGFydGtl LWRpY2UtcHJvZmlsZS0wMw0KPiANCj4gVGhlIGRyYWZ0IGRyYWZ0LWhhcnRrZS1kaWNlLXByb2Zp bGUtMDMgaGFzIG1hZGUgcHJvZ3Jlc3Mgb24gb3VyIERUTFMgUHJvZmlsZQ0KPiBXRyBpdGVtLCBh bmQgaGFkIGdvb2QgY29uc2Vuc3VzIGR1cmluZyBvdXIgTG9uZG9uIG1lZXRpbmcuIFRoaXMgZW1h aWwgaXMgYQ0KPiBjYWxsIGZvciBjb25maXJtYXRpb24gb2YgdGhhdCBjb25zZW5zdXMuICBQbGVh c2UgcmVzcG9uZCBpZiB5b3Ugc3VwcG9ydCB0aGUNCj4gYWRvcHRpb24gb2YgdGhpcyBkb2N1bWVu dCBhcyB0aGUgYmFzaXMgZm9yIHRoaXMgd29yayBpdGVtLg0KPiANCj4gSWYgYWRvcHRlZCB0aGUg YXV0aG9ycyB3b3VsZCBvZiBjb3Vyc2UgbmVlZCB0byB0YWtlIGludG8gYWNjb3VudCB0aGUgZmVl ZGJhY2sNCj4gcmVjZWl2ZWQgZHVyaW5nIHRoZSBESUNFIG1lZXRpbmcgaW4gTG9uZG9uLCBhbmQg Y2hhbmdlcyBnb2luZyBmb3J3YXJkLg0KPiANCj4gPkZyb20gb3VyIGNoYXJ0ZXI6DQo+IA0KPiAg IERlYyAyMDEzIC0gV0cgZG9jdW1lbnQgZm9yIERUTFMgZm9yIENvbnN0cmFpbmVkIEVudmlyb25t ZW50cyBwcm9maWxlDQo+IA0KPiBXaGljaCBrZWVwcyB1cyBvbiB0cmFjayB0byBkZWxpdmVyOg0K PiANCj4gICBNYXkgMjAxNCAtIERUTFMgZm9yIElvVCBwcm9maWxlIHNwZWNpZmljYXRpb24gc3Vi bWl0dGVkIHRvIHRoZSBJRVNHIGZvcg0KPiBwdWJsaWNhdGlvbiBhcyBzdGFuZGFyZHMgdHJhY2sN Cj4gDQo+IFphY2ggU2hlbGJ5DQo+IERpcmVjdG9yIG9mIFRlY2hub2xvZ3kNCj4gQVJNIEludGVy bmV0IG9mIFRoaW5ncyBCVQ0KPiB3d3cuYXJtLmNvbQ0KPiBtb2JpbGU6ICsxICg0MDgpIDIwMy05 NDM0DQo+IFNreXBlOiB6ZHNoZWxieQ0KPiBMaW5rZWRJbjogZmkubGlua2VkaW4uY29tL2luL3ph Y2hzaGVsYnkvDQo+IA0KPiANCj4gLS0gSU1QT1JUQU5UIE5PVElDRTogVGhlIGNvbnRlbnRzIG9m IHRoaXMgZW1haWwgYW5kIGFueSBhdHRhY2htZW50cyBhcmUNCj4gY29uZmlkZW50aWFsIGFuZCBt YXkgYWxzbyBiZSBwcml2aWxlZ2VkLiBJZiB5b3UgYXJlIG5vdCB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LA0KPiBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHkgYW5kIGRvIG5vdCBk aXNjbG9zZSB0aGUgY29udGVudHMgdG8gYW55DQo+IG90aGVyIHBlcnNvbiwgdXNlIGl0IGZvciBh bnkgcHVycG9zZSwgb3Igc3RvcmUgb3IgY29weSB0aGUgaW5mb3JtYXRpb24gaW4gYW55DQo+IG1l ZGl1bS4gIFRoYW5rIHlvdS4NCj4gDQo+IEFSTSBMaW1pdGVkLCBSZWdpc3RlcmVkIG9mZmljZSAx MTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosDQo+IFJlZ2lzdGVyZWQgaW4gRW5n bGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAgMjU1NzU5MCBBUk0gSG9sZGluZ3MgcGxjLA0KPiBS ZWdpc3RlcmVkIG9mZmljZSAxMTAgRnVsYm91cm4gUm9hZCwgQ2FtYnJpZGdlIENCMSA5TkosIFJl Z2lzdGVyZWQgaW4NCj4gRW5nbGFuZCAmIFdhbGVzLCBDb21wYW55IE5vOiAgMjU0ODc4Mg0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gZHRs cy1pb3QgbWFpbGluZyBsaXN0DQo+IGR0bHMtaW90QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vZHRscy1pb3QNCg== From nobody Tue Mar 11 04:44:21 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1DC611A070E for ; Tue, 11 Mar 2014 04:44:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HSPKwgm1D2Ti for ; Tue, 11 Mar 2014 04:44:17 -0700 (PDT) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) by ietfa.amsl.com (Postfix) with ESMTP id A328A1A066C for ; Tue, 11 Mar 2014 04:44:16 -0700 (PDT) Received: by mail-wi0-f176.google.com with SMTP id hr14so721255wib.9 for ; Tue, 11 Mar 2014 04:44:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=2r/5XwY6FYzAaDbvXkw7Oh3ApKfaHniafgb69SgUNVY=; b=UVP4bPiV/DDWhv++4KVr3AnT9yOgk1nvT322BSvyhngx9eDLMpVzvx677K23wuu20N edLNj8DaDCdFncy9TtMcR4MdIV3n79VK47AR1ODv5prS59KKjtKxprsLRRh+7DS1Pnhn eWv6rD29w8iCoED+Y74cmZoxLdT7K30e7KuescYz1cpZ/MOrt9nSEYSMOw5ER/C5BjK+ jewSrVx6IuRb6TKKnLt7Tb6daaFKmn1sesDJ/nWWkVFTOQxAh8W14djBK6AvQskEEjLW RboauwAII+GqhPfgkAvgxffw/UrWsJBUCA6UsdOYjkFIpVG38V7HHPX9LcdaEyJvjJbA zsRQ== MIME-Version: 1.0 X-Received: by 10.194.48.100 with SMTP id k4mr7210705wjn.49.1394538250526; Tue, 11 Mar 2014 04:44:10 -0700 (PDT) Received: by 10.194.110.166 with HTTP; Tue, 11 Mar 2014 04:44:10 -0700 (PDT) In-Reply-To: <88AF60D4-06AF-4223-867F-29AE789AA9DD@arm.com> References: <88AF60D4-06AF-4223-867F-29AE789AA9DD@arm.com> Date: Tue, 11 Mar 2014 17:14:10 +0530 Message-ID: From: Suhas Nandakumar To: Zach Shelby Content-Type: multipart/alternative; boundary=047d7b86de400c631804f4533dd2 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/QyVEqUOm1UTeJ705qaaFwCosgEE Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Mar 2014 11:44:19 -0000 --047d7b86de400c631804f4533dd2 Content-Type: text/plain; charset=ISO-8859-1 + 1. Cheers Suhas On Tue, Mar 11, 2014 at 12:51 AM, Zach Shelby wrote: > The draft draft-hartke-dice-profile-03 has made progress on our DTLS > Profile WG item, and had good consensus during our London meeting. This > email is a call for confirmation of that consensus. Please respond if you > support the adoption of this document as the basis for this work item. > > If adopted the authors would of course need to take into account the > feedback received during the DICE meeting in London, and changes going > forward. > > >From our charter: > > Dec 2013 - WG document for DTLS for Constrained Environments profile > > Which keeps us on track to deliver: > > May 2014 - DTLS for IoT profile specification submitted to the IESG for > publication as standards track > > 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 > confidential 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, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot > --047d7b86de400c631804f4533dd2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
+ 1.=A0

Cheers
Suhas


On Tue, Mar= 11, 2014 at 12:51 AM, Zach Shelby <Zach.Shelby@arm.com> w= rote:
The draft draft-hartke-dice-profile-03 has m= ade progress on our DTLS Profile WG item, and had good consensus during our= London meeting. This email is a call for confirmation of that consensus. = =A0Please respond if you support the adoption of this document as the basis= for this work item.

If adopted the authors would of course need to take into account the feedba= ck received during the DICE meeting in London, and changes going forward.
>From our charter:

=A0 Dec 2013 - WG document for DTLS for Constrained Environments profile
Which keeps us on track to deliver:

=A0 May 2014 - DTLS for IoT profile specification submitted to the IESG for= publication as standards track

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. =A0Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: =A02557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: =A02548782

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

--047d7b86de400c631804f4533dd2-- From nobody Tue Mar 11 18:04:51 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F4921A08AF for ; Tue, 11 Mar 2014 18:04:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O1jcwOfe7vRC for ; Tue, 11 Mar 2014 18:04:46 -0700 (PDT) Received: from plockton.cent.gla.ac.uk (plockton.cent.gla.ac.uk [130.209.16.75]) by ietfa.amsl.com (Postfix) with ESMTP id 9ECAA1A08AD for ; Tue, 11 Mar 2014 18:04:46 -0700 (PDT) Received: from hub02.campus.gla.ac.uk ([130.209.14.20]) by plockton.cent.gla.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1WNXb6-0005zr-6z for dtls-iot@ietf.org; Wed, 12 Mar 2014 01:04:40 +0000 Received: from cms01.campus.gla.ac.uk ([169.254.1.134]) by hub02.campus.gla.ac.uk ([130.209.14.20]) with mapi; Wed, 12 Mar 2014 01:04:39 +0000 From: Sye Loong Keoh To: "dtls-iot@ietf.org" Date: Wed, 12 Mar 2014 01:06:26 +0000 Thread-Topic: Call for WG adoption of draft-hartke-dice-profile-03 Thread-Index: Ac88lfXBPtoWHZgcS1ePalYVLmv2FAA+UeDQ Message-ID: References: <88AF60D4-06AF-4223-867F-29AE789AA9DD@arm.com> In-Reply-To: <88AF60D4-06AF-4223-867F-29AE789AA9DD@arm.com> Accept-Language: en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/YhFJjLnXBPpKNv_TWoIe1cUhSTA Subject: Re: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 01:04:49 -0000 +1=20 Cheers Sye Loong -----Original Message----- From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Tuesday, 11 March, 2014 3:21 AM To: dtls-iot@ietf.org Subject: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 The draft draft-hartke-dice-profile-03 has made progress on our DTLS Profil= e WG item, and had good consensus during our London meeting. This email is = a call for confirmation of that consensus. Please respond if you support t= he adoption of this document as the basis for this work item. If adopted the authors would of course need to take into account the feedba= ck received during the DICE meeting in London, and changes going forward. >From our charter: Dec 2013 - WG document for DTLS for Constrained Environments profile Which keeps us on track to deliver: May 2014 - DTLS for IoT profile specification submitted to the IESG for p= ublication as standards track 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, Registered in England & Wales,= Company No: 2548782 _______________________________________________ dtls-iot mailing list dtls-iot@ietf.org https://www.ietf.org/mailman/listinfo/dtls-iot From nobody Wed Mar 12 06:11:05 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 631691A098C for ; Wed, 12 Mar 2014 06:11:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.447 X-Spam-Level: X-Spam-Status: No, score=-2.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M75yAtrUei0b for ; Wed, 12 Mar 2014 06:11:00 -0700 (PDT) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id 01FBD1A0988 for ; Wed, 12 Mar 2014 06:10:59 -0700 (PDT) X-ASG-Debug-ID: 1394629852-06daaa2cd314b740001-roOjxa Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id Puy4zXHDteNIxXLV for ; Wed, 12 Mar 2014 09:10:52 -0400 (EDT) X-Barracuda-Envelope-From: Akbar.Rahman@InterDigital.com Received: from SAM.InterDigital.com ([10.30.2.11]) by smtp-out1.interdigital.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 12 Mar 2014 09:11:36 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Wed, 12 Mar 2014 09:11:35 -0400 X-ASG-Orig-Subj: RE: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Call for WG adoption of draft-hartke-dice-profile-03 Thread-Index: Ac88lfXBPtoWHZgcS1ePalYVLmv2FABXpbMg From: "Rahman, Akbar" To: "Zach Shelby" , X-OriginalArrivalTime: 12 Mar 2014 13:11:36.0125 (UTC) FILETIME=[98C2C6D0:01CF3DF4] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1394629852 X-Barracuda-URL: http://10.1.245.3:8000/cgi-mod/mark.cgi X-Virus-Scanned: by bsmtpd at interdigital.com X-Barracuda-BRTS-Status: 1 X-Barracuda-Spam-Score: 0.00 X-Barracuda-Spam-Status: No, SCORE=0.00 using per-user scores of TAG_LEVEL=1000.0 QUARANTINE_LEVEL=1000.0 KILL_LEVEL=9.0 tests= X-Barracuda-Spam-Report: Code version 3.2, rules version 3.2.3.3814 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/1IIJBFRiF5RTJuC-u2lEsAlE7ho Subject: Re: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Mar 2014 13:11:02 -0000 +1 Best Regards, Akbar -----Original Message----- From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Zach Shelby Sent: Monday, March 10, 2014 3:21 PM To: dtls-iot@ietf.org Subject: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 The draft draft-hartke-dice-profile-03 has made progress on our DTLS Profile WG item, and had good consensus during our London meeting. This email is a call for confirmation of that consensus. Please respond if you support the adoption of this document as the basis for this work item. If adopted the authors would of course need to take into account the feedback received during the DICE meeting in London, and changes going forward. >From our charter: Dec 2013 - WG document for DTLS for Constrained Environments profile Which keeps us on track to deliver: May 2014 - DTLS for IoT profile specification submitted to the IESG for publication as standards track 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 confidential 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, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ dtls-iot mailing list dtls-iot@ietf.org https://www.ietf.org/mailman/listinfo/dtls-iot From nobody Thu Mar 13 21:40:27 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13AE31A001D for ; Thu, 13 Mar 2014 21:40:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22yFqTZ8ORdT for ; Thu, 13 Mar 2014 21:40:23 -0700 (PDT) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id AA0271A0026 for ; Thu, 13 Mar 2014 21:40:22 -0700 (PDT) Received: from usa-sjc-gw1.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Fri, 14 Mar 2014 04:40:14 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw1.usa.Arm.com ([::1]) with mapi; Thu, 13 Mar 2014 21:40:23 -0700 From: Zach Shelby To: Klaus Hartke Date: Thu, 13 Mar 2014 21:40:10 -0700 Thread-Topic: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01) Thread-Index: Ac8/P4JKDaE28/VHQNafsamI4dNWhw== Message-ID: References: In-Reply-To: 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: 114031404401401102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/dZDuYETlhwPBHjTEGC9KJVMbjLs Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 04:40:26 -0000 Hi Klaus, I know you're working to put together a draft on this, but I wanted to resu= rface this thread in case others have some more input for you. Looking our deployments and use cases for DTLS, I can't find a use for eith= er renegotiation or resumption (as defined today). We do however have the problem of dynamic IP addresses changing fairly ofte= n on mobile constrained endpoints, sometimes in-between even just single Co= AP notifications. It would be very useful if DTLS 1.3 would have a mechanis= m to deal with that without requiring a new handshake each time the IP addr= ess changes. Some kind of mechanism to include the Session ID after the IP = address has changed for example. Zach On Feb 25, 2014, at 6:06 AM, Klaus Hartke wrote: > Eric Rescorla wrote: >> - There is no currently defined support for any kind of resumption. >> We need to decide if resumption is still an important feature in light >> of the trend towards more PFS and faster processors. I'm particularly >> looking for input from the IoT/DICE guys here. > > I'm not really sure what's being done in existing deployments, but I'd > be inclined to say that session resumption is not really needed. > > The feature allows a client to create a session and get a Session ID. > This Session ID can be used by the client to duplicate the session or > to later resume the previous session. The server has to store the > session state with the Session ID in a cache. > > - Duplicate the session: I'd assume that a constrained node typically > maintains only one session to a given destination. For example, with > CoAP a session can be used for as many requests as needed; CoAP does > not need a new session for every request. > > - Resume a previous session: I'm not exactly sure what a client should > do when it has established a session but hasn't used it for a while. > For example, if the client has created a session to make a CoAP > request and later wants to make another request, should it first > resume the session? Or just try to use it, get an alert, and then > resume it? Or try to use it, get an alert, and create a new session? > I'd say that the server either has the session state still (then the > client should be able to make the request right away without resuming > the session) or it doesn't (then the client has to create a new > session). > > Are there other use cases? > Are my assumptions valid? > Am I missing something? > What's implemented in existing IoT DTLS deployments? > > Best regards, > Klaus > > > > ---------- Forwarded message ---------- > From: Eric Rescorla > Date: 19 February 2014 21:40 > Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01 > To: "tls@ietf.org" > > > Folks, > > I have prepared a new version of the TLS 1.3 flows document which > should appear in the repository shortly and in the meantime can be > found at: > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.tx= t > > This version fleshes out a "recommended" set of flows: > > - 2-RTT where the client has no knowledge of the > server's capabilities. > > - 1-RTT where the client knows the server's semi-permanent > DHE/ECDHE key pair. > > - 0-RTT where the client and the server have shared anti-replay > state. > > There are still a number of open issues, but this should be clear > enough to see the direction I am trying to go. These flows are > structured so that the 1-RTT case is the base case with the 2-RTT and > 0-RTT versions being variants of the basic 1-RTT handshake. All > variants encrypt the client extensions that are not required > to define the cryptographic processing (e.g., SNI is encrypted > but curve negotiation is not). > > I think the high order bit here is whether we want to have > encrypted SNI, because that dictates the position of the DHE > exchanges with respect to the server's messages. > > There are three options here: > > - Never > - Sometimes > - Always > > The flows in this draft take the position of "Always" which is > simple. "Never" is actually simpler. "Sometimes" is the most > complicated. There are two cases where we could shave off latency if > we were willing to disclose the SNI to passive attackers (and in cases > where the client and server have never talked before.) My sense of > recent discussion is that people feel it's important to have modes > that protect SNI even if those are not the only modes. However, that > means that if we want to have non-SNI protecting modes, they are > additional complexity. Please let me know if I have misread the WG > here. > > > Here are some other things to keep in mind as you read the document. > > - Per my sense of the list, I have totally removed static RSA. If > people strongly object to that, please speak up and let me know. > > - There has been no real security analysis of this material other than > at the hand-wavy level. We clearly need that, but the first thing we > need is to be clear on whether this is approximately the right set of > points in the complexity/performance/privacy tradeoff space and then > make sure that the security properties are correct. So, if you see > something that looks wrong or even grievously wrong, don't panic (but > do point it out). > > > - There is no currently defined support for any kind of resumption. > We need to decide if resumption is still an important feature in light > of the trend towards more PFS and faster processors. I'm particularly > looking for input from the IoT/DICE guys here. > > - We will probably need to work out some of the details for DTLS, but > I wanted to get TLS nailed down first. > > - We also need to do some work on the symmetric crypto, e.g., to make > encrypt-then-MAC the default, perhaps to deprecate some ciphers, > compression, etc. I haven't forgotten that, but I want to deal with > the handshakes first. > > - As before, this incorporates ideas from a lot of different people > (and many times the same idea from different people). If you think > you should acknowledged in the text and/or acknowledgements > differently, please let me know. > > Thanks and comments welcome > -Ekr > > _______________________________________________ > 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 nobody Fri Mar 14 00:03:18 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A28D01A0064 for ; Fri, 14 Mar 2014 00:03:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w-hOD2-k_uaF for ; Fri, 14 Mar 2014 00:03:12 -0700 (PDT) Received: from mail-qc0-x229.google.com (mail-qc0-x229.google.com [IPv6:2607:f8b0:400d:c01::229]) by ietfa.amsl.com (Postfix) with ESMTP id B07721A0062 for ; Fri, 14 Mar 2014 00:03:12 -0700 (PDT) Received: by mail-qc0-f169.google.com with SMTP id i17so2438758qcy.28 for ; Fri, 14 Mar 2014 00:03:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=HA8ZUn2t6O9CjbK7Ofxiky9NFtu1x/E0NxTQFfjfOho=; b=GSaSqvJoABMrt7yP7gh/+Rd6tZowdWOa90kpNNz4GirDzqWg5WSq5xoG0q55HE81wm QV7e/wjPH1JQvHDucN0w+Bhwqt0wQKcDIHwJ4N5DO1w9opkmypjX9lR9LeFnFRNeHEFl bRQ/0F0ZHAHdgu+gwt+OXRJrJ9Vlm1JK0m4U7/SzS+TiB9atZAMfLWknaNpLzkIni8UV NU5iDZ4fxh1MVZfATvBXTCjFcsqLRKwbvQ2GtGvNWGv+gIqTBvL/WIMWNn32pdU4LAXN E5GVqTF2UBy3nxGaQoEUywsbWIJjlvTaIfiANqqQ/O29oUrW4VFoUdEuPqcc/KWkpxkX +FlA== MIME-Version: 1.0 X-Received: by 10.224.171.200 with SMTP id i8mr298429qaz.96.1394780585461; Fri, 14 Mar 2014 00:03:05 -0700 (PDT) Sender: fvidalmeca@gmail.com Received: by 10.140.39.82 with HTTP; Fri, 14 Mar 2014 00:03:05 -0700 (PDT) In-Reply-To: References: Date: Fri, 14 Mar 2014 08:03:05 +0100 X-Google-Sender-Auth: 2gFq7m9QZ7i-n2JWRQAVXJyVt4M Message-ID: From: Francisco Vidal Meca To: Zach Shelby Content-Type: multipart/alternative; boundary=001a11c2ca885627c504f48ba9ee Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/okXhBy4pLwP6sgxbsgY7Kd0Ohik Cc: tuexen@fh-muenster.de, seggelmann@fh-muenster.de, "dtls-iot@ietf.org" , Klaus Hartke , erwin.rathgeb@iem.uni-due.de Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 07:03:15 -0000 --001a11c2ca885627c504f48ba9ee Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Dear all, Not long time ago I was looking what options were available to support DTLS IP change without requiring a new handshake. That led me to a DTLS Mobility paper [1] using the Hearbeat Extension [2] and done by folks from M=FCnster and Duisburg-Essen University (CCed) which might just what Zach is looking for. Regards, Francisco [1] http://dx.doi.org/10.1007/978-3-642-25959-3_33 [2] http://tools.ietf.org/html/rfc6520 2014-03-14 5:40 GMT+01:00 Zach Shelby : > Hi Klaus, > > I know you're working to put together a draft on this, but I wanted to > resurface this thread in case others have some more input for you. > > Looking our deployments and use cases for DTLS, I can't find a use for > either renegotiation or resumption (as defined today). > > We do however have the problem of dynamic IP addresses changing fairly > often on mobile constrained endpoints, sometimes in-between even just > single CoAP notifications. It would be very useful if DTLS 1.3 would have= a > mechanism to deal with that without requiring a new handshake each time t= he > IP address changes. Some kind of mechanism to include the Session ID afte= r > the IP address has changed for example. > > Zach > > On Feb 25, 2014, at 6:06 AM, Klaus Hartke wrote: > > > Eric Rescorla wrote: > >> - There is no currently defined support for any kind of resumption. > >> We need to decide if resumption is still an important feature in light > >> of the trend towards more PFS and faster processors. I'm particularly > >> looking for input from the IoT/DICE guys here. > > > > I'm not really sure what's being done in existing deployments, but I'd > > be inclined to say that session resumption is not really needed. > > > > The feature allows a client to create a session and get a Session ID. > > This Session ID can be used by the client to duplicate the session or > > to later resume the previous session. The server has to store the > > session state with the Session ID in a cache. > > > > - Duplicate the session: I'd assume that a constrained node typically > > maintains only one session to a given destination. For example, with > > CoAP a session can be used for as many requests as needed; CoAP does > > not need a new session for every request. > > > > - Resume a previous session: I'm not exactly sure what a client should > > do when it has established a session but hasn't used it for a while. > > For example, if the client has created a session to make a CoAP > > request and later wants to make another request, should it first > > resume the session? Or just try to use it, get an alert, and then > > resume it? Or try to use it, get an alert, and create a new session? > > I'd say that the server either has the session state still (then the > > client should be able to make the request right away without resuming > > the session) or it doesn't (then the client has to create a new > > session). > > > > Are there other use cases? > > Are my assumptions valid? > > Am I missing something? > > What's implemented in existing IoT DTLS deployments? > > > > Best regards, > > Klaus > > > > > > > > ---------- Forwarded message ---------- > > From: Eric Rescorla > > Date: 19 February 2014 21:40 > > Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01 > > To: "tls@ietf.org" > > > > > > Folks, > > > > I have prepared a new version of the TLS 1.3 flows document which > > should appear in the repository shortly and in the meantime can be > > found at: > > > > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3.tx= t > > > > This version fleshes out a "recommended" set of flows: > > > > - 2-RTT where the client has no knowledge of the > > server's capabilities. > > > > - 1-RTT where the client knows the server's semi-permanent > > DHE/ECDHE key pair. > > > > - 0-RTT where the client and the server have shared anti-replay > > state. > > > > There are still a number of open issues, but this should be clear > > enough to see the direction I am trying to go. These flows are > > structured so that the 1-RTT case is the base case with the 2-RTT and > > 0-RTT versions being variants of the basic 1-RTT handshake. All > > variants encrypt the client extensions that are not required > > to define the cryptographic processing (e.g., SNI is encrypted > > but curve negotiation is not). > > > > I think the high order bit here is whether we want to have > > encrypted SNI, because that dictates the position of the DHE > > exchanges with respect to the server's messages. > > > > There are three options here: > > > > - Never > > - Sometimes > > - Always > > > > The flows in this draft take the position of "Always" which is > > simple. "Never" is actually simpler. "Sometimes" is the most > > complicated. There are two cases where we could shave off latency if > > we were willing to disclose the SNI to passive attackers (and in cases > > where the client and server have never talked before.) My sense of > > recent discussion is that people feel it's important to have modes > > that protect SNI even if those are not the only modes. However, that > > means that if we want to have non-SNI protecting modes, they are > > additional complexity. Please let me know if I have misread the WG > > here. > > > > > > Here are some other things to keep in mind as you read the document. > > > > - Per my sense of the list, I have totally removed static RSA. If > > people strongly object to that, please speak up and let me know. > > > > - There has been no real security analysis of this material other than > > at the hand-wavy level. We clearly need that, but the first thing we > > need is to be clear on whether this is approximately the right set of > > points in the complexity/performance/privacy tradeoff space and then > > make sure that the security properties are correct. So, if you see > > something that looks wrong or even grievously wrong, don't panic (but > > do point it out). > > > > > > - There is no currently defined support for any kind of resumption. > > We need to decide if resumption is still an important feature in light > > of the trend towards more PFS and faster processors. I'm particularly > > looking for input from the IoT/DICE guys here. > > > > - We will probably need to work out some of the details for DTLS, but > > I wanted to get TLS nailed down first. > > > > - We also need to do some work on the symmetric crypto, e.g., to make > > encrypt-then-MAC the default, perhaps to deprecate some ciphers, > > compression, etc. I haven't forgotten that, but I want to deal with > > the handshakes first. > > > > - As before, this incorporates ideas from a lot of different people > > (and many times the same idea from different people). If you think > > you should acknowledged in the text and/or acknowledgements > > differently, please let me know. > > > > Thanks and comments welcome > > -Ekr > > > > _______________________________________________ > > 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 > confidential 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 th= e > information in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot > --001a11c2ca885627c504f48ba9ee Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Dear all,

Not long time ago I = was looking what options were available to support DTLS IP change without r= equiring a new handshake. That led me to a DTLS Mobility paper [1] using th= e Hearbeat Extension [2] and done by folks from M=FCnster and Duisburg-Esse= n University (CCed) which might just what Zach is looking for.

Regards,
Francisco


2014-03-14 5:40 GMT+01:00 Zach Shelby <Zach.Shelby@arm.com><= /span>:
Hi Klaus,

I know you're working to put together a draft on this, but I wanted to = resurface this thread in case others have some more input for you.

Looking our deployments and use cases for DTLS, I can't find a use for = either renegotiation or resumption (as defined today).

We do however have the problem of dynamic IP addresses changing fairly ofte= n on mobile constrained endpoints, sometimes in-between even just single Co= AP notifications. It would be very useful if DTLS 1.3 would have a mechanis= m to deal with that without requiring a new handshake each time the IP addr= ess changes. Some kind of mechanism to include the Session ID after the IP = address has changed for example.

Zach

On Feb 25, 2014, at 6:06 AM, Klaus Hartke <hartke@tzi.org> wrote:

> Eric Rescorla wrote:
>> - There is no currently defined support for any kind of resumption= .
>> We need to decide if resumption is still an important feature in l= ight
>> of the trend towards more PFS and faster processors. =A0I'm pa= rticularly
>> looking for input from the IoT/DICE guys here.
>
> I'm not really sure what's being done in existing deployments,= but I'd
> be inclined to say that session resumption is not really needed.
>
> The feature allows a client to create a session and get a Session ID.<= br> > This Session ID can be used by the client to duplicate the session or<= br> > to later resume the previous session. The server has to store the
> session state with the Session ID in a cache.
>
> - Duplicate the session: I'd assume that a constrained node typica= lly
> maintains only one session to a given destination. For example, with > CoAP a session can be used for as many requests as needed; CoAP does > not need a new session for every request.
>
> - Resume a previous session: I'm not exactly sure what a client sh= ould
> do when it has established a session but hasn't used it for a whil= e.
> For example, if the client has created a session to make a CoAP
> request and later wants to make another request, should it first
> resume the session? Or just try to use it, get an alert, and then
> resume it? Or try to use it, get an alert, and create a new session? > I'd say that the server either has the session state still (then t= he
> client should be able to make the request right away without resuming<= br> > the session) or it doesn't (then the client has to create a new > session).
>
> Are there other use cases?
> Are my assumptions valid?
> Am I missing something?
> What's implemented in existing IoT DTLS deployments?
>
> Best regards,
> Klaus
>
>
>
> ---------- Forwarded message ----------
> From: Eric Rescorla <ekr@rtfm.com>
> Date: 19 February 2014 21:40
> Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01
> To: "tls@ietf.org" <<= a href=3D"mailto:tls@ietf.org">tls@ietf.org>
>
>
> Folks,
>
> I have prepared a new version of the TLS 1.3 flows document which
> should appear in the repository shortly and in the meantime can be
> found at:
>
> https://github.com/tlswg/tls13-spec/blob= /master/draft-rescorla-tls-1.3.txt
>
> This version fleshes out a "recommended" set of flows:
>
> - 2-RTT where the client has no knowledge of the
> =A0server's capabilities.
>
> - 1-RTT where the client knows the server's semi-permanent
> =A0DHE/ECDHE key pair.
>
> - 0-RTT where the client and the server have shared anti-replay
> =A0state.
>
> There are still a number of open issues, but this should be clear
> enough to see the direction I am trying to go. These flows are
> structured so that the 1-RTT case is the base case with the 2-RTT and<= br> > 0-RTT versions being variants of the basic 1-RTT handshake. All
> variants encrypt the client extensions that are not required
> to define the cryptographic processing (e.g., SNI is encrypted
> but curve negotiation is not).
>
> I think the high order bit here is whether we want to have
> encrypted SNI, because that dictates the position of the DHE
> exchanges with respect to the server's messages.
>
> There are three options here:
>
> - Never
> - Sometimes
> - Always
>
> The flows in this draft take the position of "Always" which = is
> simple. "Never" is actually simpler. "Sometimes" i= s the most
> complicated. =A0There are two cases where we could shave off latency i= f
> we were willing to disclose the SNI to passive attackers (and in cases=
> where the client and server have never talked before.) My sense of
> recent discussion is that people feel it's important to have modes=
> that protect SNI even if those are not the only modes. However, that > means that if we want to have non-SNI protecting modes, they are
> additional complexity. Please let me know if I have misread the WG
> here.
>
>
> Here are some other things to keep in mind as you read the document. >
> - Per my sense of the list, I have totally removed static RSA. =A0If > people strongly object to that, please speak up and let me know.
>
> - There has been no real security analysis of this material other than=
> at the hand-wavy level. We clearly need that, but the first thing we > need is to be clear on whether this is approximately the right set of<= br> > points in the complexity/performance/privacy tradeoff space and then > make sure that the security properties are correct. So, if you see
> something that looks wrong or even grievously wrong, don't panic (= but
> do point it out).
>
>
> - There is no currently defined support for any kind of resumption. > We need to decide if resumption is still an important feature in light=
> of the trend towards more PFS and faster processors. =A0I'm partic= ularly
> looking for input from the IoT/DICE guys here.
>
> - We will probably need to work out some of the details for DTLS, but<= br> > I wanted to get TLS nailed down first.
>
> - We also need to do some work on the symmetric crypto, e.g., to make<= br> > encrypt-then-MAC the default, perhaps to deprecate some ciphers,
> compression, etc. I haven't forgotten that, but I want to deal wit= h
> the handshakes first.
>
> - As before, this incorporates ideas from a lot of different people > (and many times the same idea from different people). If you think
> you should acknowledged in the text and/or acknowledgements
> differently, please let me know.
>
> Thanks and comments welcome
> -Ekr
>
> _______________________________________________
> 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. =A0Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regist= ered in England & Wales, Company No: =A02557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, R= egistered in England & Wales, Company No: =A02548782

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

--001a11c2ca885627c504f48ba9ee-- From nobody Fri Mar 14 01:52:55 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC9F11A00C0 for ; Fri, 14 Mar 2014 01:52:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W394mdBPyLUR for ; Fri, 14 Mar 2014 01:52:45 -0700 (PDT) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id F0CFD1A00BB for ; Fri, 14 Mar 2014 01:52:44 -0700 (PDT) Received: from mail218-tx2-R.bigfish.com (10.9.14.253) by TX2EHSOBE007.bigfish.com (10.9.40.27) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Mar 2014 08:52:38 +0000 Received: from mail218-tx2 (localhost [127.0.0.1]) by mail218-tx2-R.bigfish.com (Postfix) with ESMTP id E97B27E0425; Fri, 14 Mar 2014 08:52:37 +0000 (UTC) X-Forefront-Antispam-Report: CIP:206.191.240.53; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:error; EFVD:FOP X-SpamScore: -33 X-BigFish: VPS-33(z579ehz98dI15d6O9371I15bfK542I1432I9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL8275bh8275dh1de097h186068h18602ehz2dh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh25f6h2605h262fh1155h) Received: from mail218-tx2 (localhost.localdomain [127.0.0.1]) by mail218-tx2 (MessageSwitch) id 1394787155995718_12362; Fri, 14 Mar 2014 08:52:35 +0000 (UTC) Received: from TX2EHSMHS042.bigfish.com (unknown [10.9.14.238]) by mail218-tx2.bigfish.com (Postfix) with ESMTP id EE2676400C9; Fri, 14 Mar 2014 08:52:35 +0000 (UTC) Received: from mail.philips.com (206.191.240.53) by TX2EHSMHS042.bigfish.com (10.9.99.142) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Mar 2014 08:52:35 +0000 Received: from DBXPRD9003MB059.MGDPHG.emi.philips.com ([169.254.7.29]) by DBXPRD9003HT002.MGDPHG.emi.philips.com ([141.251.25.207]) with mapi id 14.16.0423.000; Fri, 14 Mar 2014 08:52:32 +0000 From: "Kumar, Sandeep" To: Zach Shelby , Klaus Hartke Thread-Topic: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01) Thread-Index: AQHPMjL9n1AEp/wQOEK0zmI1VyIl0prgGpAAgABCxEA= Date: Fri, 14 Mar 2014 08:52:31 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.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% Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Lri7MjdCZIn-Z1y8r0CrO9XlhXw Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 14 Mar 2014 08:52:52 -0000 ...snipped... > Some kind of mechanism to include the Session ID > after the IP address has changed for example. Just to add to that, sometimes the constrained endpoint may not be even awa= re of the IP or port change if behind a NAT. Although Heartbeat can try to = maintain the port assignment with quite some data usage, if a large number = of devices are present, the middle-box has to at some point clear up ports = and reassign to others breaking the IP/port combination. It would be nice t= o have a SessionID within the record layer that identifies the session with= the endpoint without resorting to the IP/port combination to retrieve the= session. Sandeep > -----Original Message----- > From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Zach Shelb= y > Sent: Friday, March 14, 2014 5:40 AM > To: Klaus Hartke > Cc: dtls-iot@ietf.org > Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: draft- > rescorla-tls13-new-flows-01) > > Hi Klaus, > > I know you're working to put together a draft on this, but I wanted to > resurface this thread in case others have some more input for you. > > Looking our deployments and use cases for DTLS, I can't find a use for ei= ther > renegotiation or resumption (as defined today). > > We do however have the problem of dynamic IP addresses changing fairly > often on mobile constrained endpoints, sometimes in-between even just > single CoAP notifications. It would be very useful if DTLS 1.3 would have= a > mechanism to deal with that without requiring a new handshake each time > the IP address changes. Some kind of mechanism to include the Session ID > after the IP address has changed for example. > > Zach > > On Feb 25, 2014, at 6:06 AM, Klaus Hartke wrote: > > > Eric Rescorla wrote: > >> - There is no currently defined support for any kind of resumption. > >> We need to decide if resumption is still an important feature in > >> light of the trend towards more PFS and faster processors. I'm > >> particularly looking for input from the IoT/DICE guys here. > > > > I'm not really sure what's being done in existing deployments, but I'd > > be inclined to say that session resumption is not really needed. > > > > The feature allows a client to create a session and get a Session ID. > > This Session ID can be used by the client to duplicate the session or > > to later resume the previous session. The server has to store the > > session state with the Session ID in a cache. > > > > - Duplicate the session: I'd assume that a constrained node typically > > maintains only one session to a given destination. For example, with > > CoAP a session can be used for as many requests as needed; CoAP does > > not need a new session for every request. > > > > - Resume a previous session: I'm not exactly sure what a client should > > do when it has established a session but hasn't used it for a while. > > For example, if the client has created a session to make a CoAP > > request and later wants to make another request, should it first > > resume the session? Or just try to use it, get an alert, and then > > resume it? Or try to use it, get an alert, and create a new session? > > I'd say that the server either has the session state still (then the > > client should be able to make the request right away without resuming > > the session) or it doesn't (then the client has to create a new > > session). > > > > Are there other use cases? > > Are my assumptions valid? > > Am I missing something? > > What's implemented in existing IoT DTLS deployments? > > > > Best regards, > > Klaus > > > > > > > > ---------- Forwarded message ---------- > > From: Eric Rescorla > > Date: 19 February 2014 21:40 > > Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01 > > To: "tls@ietf.org" > > > > > > Folks, > > > > I have prepared a new version of the TLS 1.3 flows document which > > should appear in the repository shortly and in the meantime can be > > found at: > > > > https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3 > > .txt > > > > This version fleshes out a "recommended" set of flows: > > > > - 2-RTT where the client has no knowledge of the server's > > capabilities. > > > > - 1-RTT where the client knows the server's semi-permanent DHE/ECDHE > > key pair. > > > > - 0-RTT where the client and the server have shared anti-replay > > state. > > > > There are still a number of open issues, but this should be clear > > enough to see the direction I am trying to go. These flows are > > structured so that the 1-RTT case is the base case with the 2-RTT and > > 0-RTT versions being variants of the basic 1-RTT handshake. All > > variants encrypt the client extensions that are not required to define > > the cryptographic processing (e.g., SNI is encrypted but curve > > negotiation is not). > > > > I think the high order bit here is whether we want to have encrypted > > SNI, because that dictates the position of the DHE exchanges with > > respect to the server's messages. > > > > There are three options here: > > > > - Never > > - Sometimes > > - Always > > > > The flows in this draft take the position of "Always" which is simple. > > "Never" is actually simpler. "Sometimes" is the most complicated. > > There are two cases where we could shave off latency if we were > > willing to disclose the SNI to passive attackers (and in cases where > > the client and server have never talked before.) My sense of recent > > discussion is that people feel it's important to have modes that > > protect SNI even if those are not the only modes. However, that means > > that if we want to have non-SNI protecting modes, they are additional > > complexity. Please let me know if I have misread the WG here. > > > > > > Here are some other things to keep in mind as you read the document. > > > > - Per my sense of the list, I have totally removed static RSA. If > > people strongly object to that, please speak up and let me know. > > > > - There has been no real security analysis of this material other than > > at the hand-wavy level. We clearly need that, but the first thing we > > need is to be clear on whether this is approximately the right set of > > points in the complexity/performance/privacy tradeoff space and then > > make sure that the security properties are correct. So, if you see > > something that looks wrong or even grievously wrong, don't panic (but > > do point it out). > > > > > > - There is no currently defined support for any kind of resumption. > > We need to decide if resumption is still an important feature in light > > of the trend towards more PFS and faster processors. I'm particularly > > looking for input from the IoT/DICE guys here. > > > > - We will probably need to work out some of the details for DTLS, but > > I wanted to get TLS nailed down first. > > > > - We also need to do some work on the symmetric crypto, e.g., to make > > encrypt-then-MAC the default, perhaps to deprecate some ciphers, > > compression, etc. I haven't forgotten that, but I want to deal with > > the handshakes first. > > > > - As before, this incorporates ideas from a lot of different people > > (and many times the same idea from different people). If you think you > > should acknowledged in the text and/or acknowledgements differently, > > please let me know. > > > > Thanks and comments welcome > > -Ekr > > > > _______________________________________________ > > 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 > confidential and may also be privileged. If you are not the intended reci= pient, > 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, > Registered in England & Wales, Company No: 2557590 ARM Holdings plc, > Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in > England & Wales, Company No: 2548782 > > _______________________________________________ > 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 nobody Mon Mar 17 05:12:21 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 290271A03C6 for ; Mon, 17 Mar 2014 05:12:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.396 X-Spam-Level: X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UO7guFtEkTvV for ; Mon, 17 Mar 2014 05:12:15 -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 95BD11A02DA for ; Mon, 17 Mar 2014 05:12:12 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,669,1389740400"; d="p7s'?scan'208,217";a="263571964" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-1.rz.rwth-aachen.de with ESMTP; 17 Mar 2014 13:12:03 +0100 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 8195913DA67; Mon, 17 Mar 2014 13:12:03 +0100 (CET) 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 id 14.01.0218.012; Mon, 17 Mar 2014 13:12:03 +0100 From: Rene Hummen To: "Kumar, Sandeep" Thread-Topic: dtls-iot Digest, Vol 10, Issue 6 Thread-Index: AQHPP7fPcBQX241MrUa4NC4blUZ/iprlJACA Date: Mon, 17 Mar 2014 12:12:02 +0000 Message-ID: <672709B3-E816-47ED-87AA-B45E8A9AF1F3@comsys.rwth-aachen.de> References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [137.226.12.33] Content-Type: multipart/signed; boundary="Apple-Mail=_72457AC1-8688-403D-AA0F-D24BB874AD8B"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/YY7GzPK9sAPzWwetc87pNsux3t8 Cc: Zach Shelby , "dtls-iot@ietf.org" , Klaus Hartke Subject: Re: [Dtls-iot] dtls-iot Digest, Vol 10, Issue 6 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 12:12:19 -0000 --Apple-Mail=_72457AC1-8688-403D-AA0F-D24BB874AD8B Content-Type: multipart/alternative; boundary="Apple-Mail=_0539EDC5-E11A-4DE3-9B00-C0B2C82055CF" --Apple-Mail=_0539EDC5-E11A-4DE3-9B00-C0B2C82055CF Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 14 Mar 2014, at 20:01, dtls-iot-request@ietf.org wrote: > ...snipped... >> Some kind of mechanism to include the Session ID >> after the IP address has changed for example. >=20 > Just to add to that, sometimes the constrained endpoint may not be = even aware of the IP or port change if behind a NAT. Although Heartbeat = can try to maintain the port assignment with quite some data usage, if a = large number of devices are present, the middle-box has to at some point = clear up ports and reassign to others breaking the IP/port combination. = It would be nice to have a SessionID within the record layer that = identifies the session with the endpoint without resorting to the = IP/port combination to retrieve the session. Another scenario that potentially requires undesirable heartbeats is = related to on-path, soft-state middlebox services such as stateful = firewalls. Specifically, RFC6092 REC-14 [1] specifies: "A state record for a UDP flow where both source and destination ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.=94 Hence, these middleboxes at least require heartbeats each two minutes. = With session resumption, heartbeats could be omitted for intermittent = communication. Instead, a session could be resumed when new data is to = be transmitted in order to re-establish the connection state at these = middleboxes without the need of performing an entire handshake. In addition, when considering memory-constrained devices that interact = with multiple other devices or services (e.g., CoAP servers), = ticket-based session resumption could help maintain session state for = more connections than would actually fit into the scarce memory = resources of the constrained device. To this end, a memory-constrained = device could offload the DTLS session state (and potentially the = corresponding upper layer protocol state) to the respective = communication partner and swap active connections that occupy its scarce = memory resources. BR, Ren=E9 [1] https://tools.ietf.org/html/rfc6092#section-3.2.3 > Sandeep >=20 >> -----Original Message----- >> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Zach = Shelby >> Sent: Friday, March 14, 2014 5:40 AM >> To: Klaus Hartke >> Cc: dtls-iot@ietf.org >> Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: = draft- >> rescorla-tls13-new-flows-01) >>=20 >> Hi Klaus, >>=20 >> I know you're working to put together a draft on this, but I wanted = to >> resurface this thread in case others have some more input for you. >>=20 >> Looking our deployments and use cases for DTLS, I can't find a use = for either >> renegotiation or resumption (as defined today). >>=20 >> We do however have the problem of dynamic IP addresses changing = fairly >> often on mobile constrained endpoints, sometimes in-between even just >> single CoAP notifications. It would be very useful if DTLS 1.3 would = have a >> mechanism to deal with that without requiring a new handshake each = time >> the IP address changes. Some kind of mechanism to include the Session = ID >> after the IP address has changed for example. >>=20 >> Zach >>=20 >> On Feb 25, 2014, at 6:06 AM, Klaus Hartke wrote: >>=20 >>> Eric Rescorla wrote: >>>> - There is no currently defined support for any kind of resumption. >>>> We need to decide if resumption is still an important feature in >>>> light of the trend towards more PFS and faster processors. I'm >>>> particularly looking for input from the IoT/DICE guys here. >>>=20 >>> I'm not really sure what's being done in existing deployments, but = I'd >>> be inclined to say that session resumption is not really needed. >>>=20 >>> The feature allows a client to create a session and get a Session = ID. >>> This Session ID can be used by the client to duplicate the session = or >>> to later resume the previous session. The server has to store the >>> session state with the Session ID in a cache. >>>=20 >>> - Duplicate the session: I'd assume that a constrained node = typically >>> maintains only one session to a given destination. For example, with >>> CoAP a session can be used for as many requests as needed; CoAP does >>> not need a new session for every request. >>>=20 >>> - Resume a previous session: I'm not exactly sure what a client = should >>> do when it has established a session but hasn't used it for a while. >>> For example, if the client has created a session to make a CoAP >>> request and later wants to make another request, should it first >>> resume the session? Or just try to use it, get an alert, and then >>> resume it? Or try to use it, get an alert, and create a new session? >>> I'd say that the server either has the session state still (then the >>> client should be able to make the request right away without = resuming >>> the session) or it doesn't (then the client has to create a new >>> session). >>>=20 >>> Are there other use cases? >>> Are my assumptions valid? >>> Am I missing something? >>> What's implemented in existing IoT DTLS deployments? >>>=20 >>> Best regards, >>> Klaus >>>=20 >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: Eric Rescorla >>> Date: 19 February 2014 21:40 >>> Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01 >>> To: "tls@ietf.org" >>>=20 >>>=20 >>> Folks, >>>=20 >>> I have prepared a new version of the TLS 1.3 flows document which >>> should appear in the repository shortly and in the meantime can be >>> found at: >>>=20 >>> = https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3 >>> .txt >>>=20 >>> This version fleshes out a "recommended" set of flows: >>>=20 >>> - 2-RTT where the client has no knowledge of the server's >>> capabilities. >>>=20 >>> - 1-RTT where the client knows the server's semi-permanent = DHE/ECDHE >>> key pair. >>>=20 >>> - 0-RTT where the client and the server have shared anti-replay >>> state. >>>=20 >>> There are still a number of open issues, but this should be clear >>> enough to see the direction I am trying to go. These flows are >>> structured so that the 1-RTT case is the base case with the 2-RTT = and >>> 0-RTT versions being variants of the basic 1-RTT handshake. All >>> variants encrypt the client extensions that are not required to = define >>> the cryptographic processing (e.g., SNI is encrypted but curve >>> negotiation is not). >>>=20 >>> I think the high order bit here is whether we want to have encrypted >>> SNI, because that dictates the position of the DHE exchanges with >>> respect to the server's messages. >>>=20 >>> There are three options here: >>>=20 >>> - Never >>> - Sometimes >>> - Always >>>=20 >>> The flows in this draft take the position of "Always" which is = simple. >>> "Never" is actually simpler. "Sometimes" is the most complicated. >>> There are two cases where we could shave off latency if we were >>> willing to disclose the SNI to passive attackers (and in cases where >>> the client and server have never talked before.) My sense of recent >>> discussion is that people feel it's important to have modes that >>> protect SNI even if those are not the only modes. However, that = means >>> that if we want to have non-SNI protecting modes, they are = additional >>> complexity. Please let me know if I have misread the WG here. >>>=20 >>>=20 >>> Here are some other things to keep in mind as you read the document. >>>=20 >>> - Per my sense of the list, I have totally removed static RSA. If >>> people strongly object to that, please speak up and let me know. >>>=20 >>> - There has been no real security analysis of this material other = than >>> at the hand-wavy level. We clearly need that, but the first thing we >>> need is to be clear on whether this is approximately the right set = of >>> points in the complexity/performance/privacy tradeoff space and then >>> make sure that the security properties are correct. So, if you see >>> something that looks wrong or even grievously wrong, don't panic = (but >>> do point it out). >>>=20 >>>=20 >>> - There is no currently defined support for any kind of resumption. >>> We need to decide if resumption is still an important feature in = light >>> of the trend towards more PFS and faster processors. I'm = particularly >>> looking for input from the IoT/DICE guys here. >>>=20 >>> - We will probably need to work out some of the details for DTLS, = but >>> I wanted to get TLS nailed down first. >>>=20 >>> - We also need to do some work on the symmetric crypto, e.g., to = make >>> encrypt-then-MAC the default, perhaps to deprecate some ciphers, >>> compression, etc. I haven't forgotten that, but I want to deal with >>> the handshakes first. >>>=20 >>> - As before, this incorporates ideas from a lot of different people >>> (and many times the same idea from different people). If you think = you >>> should acknowledged in the text and/or acknowledgements differently, >>> please let me know. >>>=20 >>> Thanks and comments welcome >>> -Ekr >>>=20 >>> _______________________________________________ >>> dtls-iot mailing list >>> dtls-iot@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtls-iot >>>=20 >>=20 >> 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/ >>=20 >>=20 >> -- IMPORTANT NOTICE: The contents of this email and any attachments = are >> confidential 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. >>=20 >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >> Registered in England & Wales, Company No: 2557590 ARM Holdings plc, >> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in >> England & Wales, Company No: 2548782 >>=20 >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >=20 > ________________________________ > 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. -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_0539EDC5-E11A-4DE3-9B00-C0B2C82055CF Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 14 = Mar 2014, at 20:01, dtls-iot-request@ietf.org = wrote:
...snipped...
Some kind of mechanism to include the Session ID
after the IP = address has changed for example.

Just to add to that, sometimes = the constrained endpoint may not be even aware of the IP or port change = if behind a NAT. Although Heartbeat can try to maintain the port = assignment with quite some data usage, if a large number of devices are = present, the middle-box has to at some point clear up ports and reassign = to others breaking the IP/port combination. It would be nice to have a = SessionID within the record layer that identifies the session with the = endpoint without resorting to the  IP/port combination to retrieve = the session.

Another scenario that potentially = requires undesirable heartbeats is related to on-path, soft-state = middlebox services such as stateful firewalls. Specifically, RFC6092 = REC-14 [1] specifies:
   "A state record for a UDP = flow where both source and
   destination ports are = outside the well-known port range
   (ports 0-1023) = MUST NOT expire in less than two minutes of idle time.
  =  The value of the UDP state record idle timer MAY be = configurable.
   The DEFAULT is five = minutes.=94
Hence, these middleboxes at least require = heartbeats each two minutes. With session resumption, heartbeats could = be omitted for intermittent communication. Instead, a session could be = resumed when new data is to be transmitted in order to re-establish the = connection state at these middleboxes without the need of performing an = entire handshake.


In addition, = when considering memory-constrained devices that interact with multiple = other devices or services (e.g., CoAP servers), ticket-based session = resumption could help maintain session state for more connections than = would actually fit into the scarce memory resources of the constrained = device. To this end, a memory-constrained device could offload the DTLS = session state (and potentially the corresponding upper layer protocol = state) to the respective communication partner and swap active = connections that occupy its scarce memory = resources.

BR,
Ren=E9




Sandeep

-----Original Message-----
From: dtls-iot [mailto:dtls-iot-bounces@ietf.org= ] On Behalf Of Zach Shelby
Sent: Friday, March 14, 2014 5:40 = AM
To: Klaus Hartke
Cc: dtls-iot@ietf.org
Subject: Re: = [Dtls-iot] Session resumption (was: [TLS] New draft: = draft-
rescorla-tls13-new-flows-01)

Hi Klaus,

I know = you're working to put together a draft on this, but I wanted = to
resurface this thread in case others have some more input for = you.

Looking our deployments and use cases for DTLS, I can't find = a use for either
renegotiation or resumption (as defined = today).

We do however have the problem of dynamic IP addresses = changing fairly
often on mobile constrained endpoints, sometimes = in-between even just
single CoAP notifications. It would be very = useful if DTLS 1.3 would have a
mechanism to deal with that without = requiring a new handshake each time
the IP address changes. Some kind = of mechanism to include the Session ID
after the IP address has = changed for example.

Zach

On Feb 25, 2014, at 6:06 AM, = Klaus Hartke <hartke@tzi.org> = wrote:

Eric Rescorla = wrote:
- There is no currently defined = support for any kind of resumption.
We need to decide if resumption = is still an important feature in
light of the trend towards more PFS = and faster processors.  I'm
particularly looking for input from = the IoT/DICE guys here.

I'm not really sure what's = being done in existing deployments, but I'd
be inclined to say that = session resumption is not really needed.

The feature allows a = client to create a session and get a Session ID.
This Session ID can = be used by the client to duplicate the session or
to later resume the = previous session. The server has to store the
session state with the = Session ID in a cache.

- Duplicate the session: I'd assume that a = constrained node typically
maintains only one session to a given = destination. For example, with
CoAP a session can be used for as many = requests as needed; CoAP does
not need a new session for every = request.

- Resume a previous session: I'm not exactly sure what a = client should
do when it has established a session but hasn't used it = for a while.
For example, if the client has created a session to make = a CoAP
request and later wants to make another request, should it = first
resume the session? Or just try to use it, get an alert, and = then
resume it? Or try to use it, get an alert, and create a new = session?
I'd say that the server either has the session state still = (then the
client should be able to make the request right away = without resuming
the session) or it doesn't (then the client has to = create a new
session).

Are there other use cases?
Are my = assumptions valid?
Am I missing something?
What's implemented in = existing IoT DTLS deployments?

Best = regards,
Klaus



---------- Forwarded message = ----------
From: Eric Rescorla <ekr@rtfm.com>
Date: 19 February = 2014 21:40
Subject: [TLS] New draft: = draft-rescorla-tls13-new-flows-01
To: "tls@ietf.org" <tls@ietf.org>


Folks,
I have prepared a new version of the TLS 1.3 flows document = which
should appear in the repository shortly and in the meantime can = be
found at:

https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1= .3
.txt

This version fleshes out a "recommended" set of = flows:

- 2-RTT where the client has no knowledge of the =  server's
capabilities.

- 1-RTT where the client knows = the server's semi-permanent  DHE/ECDHE
key pair.

- 0-RTT = where the client and the server have shared = anti-replay
state.

There are still a number of open issues, = but this should be clear
enough to see the direction I am trying to = go. These flows are
structured so that the 1-RTT case is the base = case with the 2-RTT and
0-RTT versions being variants of the basic = 1-RTT handshake. All
variants encrypt the client extensions that are = not required to define
the cryptographic processing (e.g., SNI is = encrypted but curve
negotiation is not).

I think the high = order bit here is whether we want to have encrypted
SNI, because that = dictates the position of the DHE exchanges with
respect to the = server's messages.

There are three options here:

- = Never
- Sometimes
- Always

The flows in this draft take the = position of "Always" which is simple.
"Never" is actually simpler. = "Sometimes" is the most complicated.
There are two cases where we = could shave off latency if we were
willing to disclose the SNI to = passive attackers (and in cases where
the client and server have = never talked before.) My sense of recent
discussion is that people = feel it's important to have modes that
protect SNI even if those are = not the only modes. However, that means
that if we want to have = non-SNI protecting modes, they are additional
complexity. Please let = me know if I have misread the WG here.


Here are some other = things to keep in mind as you read the document.

- Per my sense = of the list, I have totally removed static RSA.  If
people = strongly object to that, please speak up and let me know.

- There = has been no real security analysis of this material other than
at the = hand-wavy level. We clearly need that, but the first thing we
need is = to be clear on whether this is approximately the right set of
points = in the complexity/performance/privacy tradeoff space and then
make = sure that the security properties are correct. So, if you = see
something that looks wrong or even grievously wrong, don't panic = (but
do point it out).


- There is no currently defined = support for any kind of resumption.
We need to decide if resumption = is still an important feature in light
of the trend towards more PFS = and faster processors.  I'm particularly
looking for input from = the IoT/DICE guys here.

- We will probably need to work out some = of the details for DTLS, but
I wanted to get TLS nailed down = first.

- We also need to do some work on the symmetric crypto, = e.g., to make
encrypt-then-MAC the default, perhaps to deprecate some = ciphers,
compression, etc. I haven't forgotten that, but I want to = deal with
the handshakes first.

- As before, this incorporates = ideas from a lot of different people
(and many times the same idea = from different people). If you think you
should acknowledged in the = text and/or acknowledgements differently,
please let me = know.

Thanks and comments = welcome
-Ekr

_______________________________________________
= dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.o= rg/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/zachshel= by/


-- IMPORTANT NOTICE: The contents of this email and = any attachments are
confidential 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,
Registered in England & Wales, Company No:  2557590 = ARM Holdings plc,
Registered office 110 Fulbourn Road, Cambridge CB1 = 9NJ, Registered in
England & Wales, Company No: =  2548782

_______________________________________________
dt= ls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.o= rg/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.

--
Dipl.-Inform. Rene Hummen, Ph.D. = Student
Chair of Communication and Distributed Systems
RWTH Aachen = University, Germany
tel: +49 241 80 21426
web: http://www.com= sys.rwth-aachen.de/team/rene-hummen/

= --Apple-Mail=_0539EDC5-E11A-4DE3-9B00-C0B2C82055CF-- --Apple-Mail=_72457AC1-8688-403D-AA0F-D24BB874AD8B 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTcxMjEyMDJaMCMGCSqGSIb3DQEJBDEWBBTaVUV0JhRI v73gZ5b4dAFpcFvv8zB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQCwZr79052B 2mbBbkfnlRg2QDJr3LK1qxuZut9R+l4Z80RgOBEzXBdJAd0/R4kVytjXQLUy5yp+Wur4giFPMafU VCYa8ICnIHyFm2QD/nPu7va1X6ZmuLUWQ09Ou1rgbsOQc6Ljjz79d4wpVM4/UslapJMuQnbOcwke GRGNUMdrmqSvyBMkcTBeIQAH7E8jtK37EuwerAorumi5N1mjA9vAjIOIQa+F+EFmTn91xF7aISqn lNvKBuLNrQw7RWRBf1ltKatJDta4t80joMCvklmqxCArRgVHTAEUno9LuAvv1tW6rY1aKHqwPJe6 osaT5W1E2qPvQiMZkwdvrlhyaHUqAAAAAAAA --Apple-Mail=_72457AC1-8688-403D-AA0F-D24BB874AD8B-- From nobody Mon Mar 17 05:15:23 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 07C761A03D5 for ; Mon, 17 Mar 2014 05:15:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.396 X-Spam-Level: X-Spam-Status: No, score=-4.396 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RxHMNZAH7R7m for ; Mon, 17 Mar 2014 05:15:17 -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 27B771A02DA for ; Mon, 17 Mar 2014 05:15:16 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.97,669,1389740400"; d="p7s'?scan'208,217";a="263572492" Received: from mail-i4.nets.rwth-aachen.de ([137.226.12.21]) by mx-1.rz.rwth-aachen.de with ESMTP; 17 Mar 2014 13:15:08 +0100 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 D620D13DA67; Mon, 17 Mar 2014 13:15:07 +0100 (CET) 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 id 14.01.0218.012; Mon, 17 Mar 2014 13:15:07 +0100 From: Rene Hummen To: "Kumar, Sandeep" , Zach Shelby , Klaus Hartke Thread-Topic: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01) Thread-Index: AQHPQdqI5cRJ3EdqoEmtf8uZ+RGXKg== Date: Mon, 17 Mar 2014 12:15:07 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US, de-DE Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [137.226.12.33] Content-Type: multipart/signed; boundary="Apple-Mail=_CC45B493-7790-463C-9883-AEA056DA03D8"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/6mpVJfU_xnt-QU0BI1Rite9lnzI Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: draft-rescorla-tls13-new-flows-01) X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Mar 2014 12:15:22 -0000 --Apple-Mail=_CC45B493-7790-463C-9883-AEA056DA03D8 Content-Type: multipart/alternative; boundary="Apple-Mail=_EAEFDC3E-5782-4556-AE4A-E7C285598257" --Apple-Mail=_EAEFDC3E-5782-4556-AE4A-E7C285598257 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 On 14 Mar 2014, at 20:01, dtls-iot-request@ietf.org wrote: > ...snipped... >> Some kind of mechanism to include the Session ID >> after the IP address has changed for example. >=20 > Just to add to that, sometimes the constrained endpoint may not be = even aware of the IP or port change if behind a NAT. Although Heartbeat = can try to maintain the port assignment with quite some data usage, if a = large number of devices are present, the middle-box has to at some point = clear up ports and reassign to others breaking the IP/port combination. = It would be nice to have a SessionID within the record layer that = identifies the session with the endpoint without resorting to the = IP/port combination to retrieve the session. Another scenario that potentially requires undesirable heartbeats is = related to on-path, soft-state middlebox services such as stateful = firewalls. Specifically, RFC6092 REC-14 [1] specifies: "A state record for a UDP flow where both source and destination ports are outside the well-known port range (ports 0-1023) MUST NOT expire in less than two minutes of idle time. The value of the UDP state record idle timer MAY be configurable. The DEFAULT is five minutes.=94 Hence, these middleboxes at least require heartbeats each two minutes. = With session resumption, heartbeats could be omitted for intermittent = communication. Instead, a session could be resumed when new data is to = be transmitted in order to re-establish the connection state at these = middleboxes without the need of performing an entire handshake. In addition, when considering memory-constrained devices that interact = with multiple other devices or services (e.g., CoAP servers), = ticket-based session resumption could help maintain session state for = more connections than would actually fit into the scarce memory = resources of the constrained device. To this end, a memory-constrained = device could offload the DTLS session state (and potentially the = corresponding upper layer protocol state) to the respective = communication partner and swap active connections that occupy its scarce = memory resources. Sorry for my prior mis-post, Ren=E9 [1] https://tools.ietf.org/html/rfc6092#section-3.2.3 >> -----Original Message----- >> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Zach = Shelby >> Sent: Friday, March 14, 2014 5:40 AM >> To: Klaus Hartke >> Cc: dtls-iot@ietf.org >> Subject: Re: [Dtls-iot] Session resumption (was: [TLS] New draft: = draft- >> rescorla-tls13-new-flows-01) >>=20 >> Hi Klaus, >>=20 >> I know you're working to put together a draft on this, but I wanted = to >> resurface this thread in case others have some more input for you. >>=20 >> Looking our deployments and use cases for DTLS, I can't find a use = for either >> renegotiation or resumption (as defined today). >>=20 >> We do however have the problem of dynamic IP addresses changing = fairly >> often on mobile constrained endpoints, sometimes in-between even just >> single CoAP notifications. It would be very useful if DTLS 1.3 would = have a >> mechanism to deal with that without requiring a new handshake each = time >> the IP address changes. Some kind of mechanism to include the Session = ID >> after the IP address has changed for example. >>=20 >> Zach >>=20 >> On Feb 25, 2014, at 6:06 AM, Klaus Hartke wrote: >>=20 >>> Eric Rescorla wrote: >>>> - There is no currently defined support for any kind of resumption. >>>> We need to decide if resumption is still an important feature in >>>> light of the trend towards more PFS and faster processors. I'm >>>> particularly looking for input from the IoT/DICE guys here. >>>=20 >>> I'm not really sure what's being done in existing deployments, but = I'd >>> be inclined to say that session resumption is not really needed. >>>=20 >>> The feature allows a client to create a session and get a Session = ID. >>> This Session ID can be used by the client to duplicate the session = or >>> to later resume the previous session. The server has to store the >>> session state with the Session ID in a cache. >>>=20 >>> - Duplicate the session: I'd assume that a constrained node = typically >>> maintains only one session to a given destination. For example, with >>> CoAP a session can be used for as many requests as needed; CoAP does >>> not need a new session for every request. >>>=20 >>> - Resume a previous session: I'm not exactly sure what a client = should >>> do when it has established a session but hasn't used it for a while. >>> For example, if the client has created a session to make a CoAP >>> request and later wants to make another request, should it first >>> resume the session? Or just try to use it, get an alert, and then >>> resume it? Or try to use it, get an alert, and create a new session? >>> I'd say that the server either has the session state still (then the >>> client should be able to make the request right away without = resuming >>> the session) or it doesn't (then the client has to create a new >>> session). >>>=20 >>> Are there other use cases? >>> Are my assumptions valid? >>> Am I missing something? >>> What's implemented in existing IoT DTLS deployments? >>>=20 >>> Best regards, >>> Klaus >>>=20 >>>=20 >>>=20 >>> ---------- Forwarded message ---------- >>> From: Eric Rescorla >>> Date: 19 February 2014 21:40 >>> Subject: [TLS] New draft: draft-rescorla-tls13-new-flows-01 >>> To: "tls@ietf.org" >>>=20 >>>=20 >>> Folks, >>>=20 >>> I have prepared a new version of the TLS 1.3 flows document which >>> should appear in the repository shortly and in the meantime can be >>> found at: >>>=20 >>> = https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1.3 >>> .txt >>>=20 >>> This version fleshes out a "recommended" set of flows: >>>=20 >>> - 2-RTT where the client has no knowledge of the server's >>> capabilities. >>>=20 >>> - 1-RTT where the client knows the server's semi-permanent = DHE/ECDHE >>> key pair. >>>=20 >>> - 0-RTT where the client and the server have shared anti-replay >>> state. >>>=20 >>> There are still a number of open issues, but this should be clear >>> enough to see the direction I am trying to go. These flows are >>> structured so that the 1-RTT case is the base case with the 2-RTT = and >>> 0-RTT versions being variants of the basic 1-RTT handshake. All >>> variants encrypt the client extensions that are not required to = define >>> the cryptographic processing (e.g., SNI is encrypted but curve >>> negotiation is not). >>>=20 >>> I think the high order bit here is whether we want to have encrypted >>> SNI, because that dictates the position of the DHE exchanges with >>> respect to the server's messages. >>>=20 >>> There are three options here: >>>=20 >>> - Never >>> - Sometimes >>> - Always >>>=20 >>> The flows in this draft take the position of "Always" which is = simple. >>> "Never" is actually simpler. "Sometimes" is the most complicated. >>> There are two cases where we could shave off latency if we were >>> willing to disclose the SNI to passive attackers (and in cases where >>> the client and server have never talked before.) My sense of recent >>> discussion is that people feel it's important to have modes that >>> protect SNI even if those are not the only modes. However, that = means >>> that if we want to have non-SNI protecting modes, they are = additional >>> complexity. Please let me know if I have misread the WG here. >>>=20 >>>=20 >>> Here are some other things to keep in mind as you read the document. >>>=20 >>> - Per my sense of the list, I have totally removed static RSA. If >>> people strongly object to that, please speak up and let me know. >>>=20 >>> - There has been no real security analysis of this material other = than >>> at the hand-wavy level. We clearly need that, but the first thing we >>> need is to be clear on whether this is approximately the right set = of >>> points in the complexity/performance/privacy tradeoff space and then >>> make sure that the security properties are correct. So, if you see >>> something that looks wrong or even grievously wrong, don't panic = (but >>> do point it out). >>>=20 >>>=20 >>> - There is no currently defined support for any kind of resumption. >>> We need to decide if resumption is still an important feature in = light >>> of the trend towards more PFS and faster processors. I'm = particularly >>> looking for input from the IoT/DICE guys here. >>>=20 >>> - We will probably need to work out some of the details for DTLS, = but >>> I wanted to get TLS nailed down first. >>>=20 >>> - We also need to do some work on the symmetric crypto, e.g., to = make >>> encrypt-then-MAC the default, perhaps to deprecate some ciphers, >>> compression, etc. I haven't forgotten that, but I want to deal with >>> the handshakes first. >>>=20 >>> - As before, this incorporates ideas from a lot of different people >>> (and many times the same idea from different people). If you think = you >>> should acknowledged in the text and/or acknowledgements differently, >>> please let me know. >>>=20 >>> Thanks and comments welcome >>> -Ekr >>>=20 >>> _______________________________________________ >>> dtls-iot mailing list >>> dtls-iot@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtls-iot >>>=20 >>=20 >> 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/ >>=20 >>=20 >> -- IMPORTANT NOTICE: The contents of this email and any attachments = are >> confidential 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. >>=20 >> ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, >> Registered in England & Wales, Company No: 2557590 ARM Holdings plc, >> Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in >> England & Wales, Company No: 2548782 >>=20 >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >=20 > ________________________________ > 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. -- Dipl.-Inform. Rene Hummen, Ph.D. Student Chair of Communication and Distributed Systems RWTH Aachen University, Germany tel: +49 241 80 21426 web: http://www.comsys.rwth-aachen.de/team/rene-hummen/ --Apple-Mail=_EAEFDC3E-5782-4556-AE4A-E7C285598257 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 On 14 = Mar 2014, at 20:01, dtls-iot-request@ietf.org = wrote:
...snipped...
Some kind of mechanism to include the Session ID
after the IP = address has changed for example.

Just to add to that, sometimes = the constrained endpoint may not be even aware of the IP or port change = if behind a NAT. Although Heartbeat can try to maintain the port = assignment with quite some data usage, if a large number of devices are = present, the middle-box has to at some point clear up ports and reassign = to others breaking the IP/port combination. It would be nice to have a = SessionID within the record layer that identifies the session with the = endpoint without resorting to the  IP/port combination to retrieve = the session.

Another scenario that = potentially requires undesirable heartbeats is related to on-path, = soft-state middlebox services such as stateful firewalls. Specifically, = RFC6092 REC-14 [1] specifies:
   "A state record for = a UDP flow where both source and
   destination = ports are outside the well-known port range
  =  (ports 0-1023) MUST NOT expire in less than two minutes of idle = time.
   The value of the UDP state record idle = timer MAY be configurable.
   The DEFAULT is five = minutes.=94
Hence, these middleboxes at least require = heartbeats each two minutes. With session resumption, heartbeats could = be omitted for intermittent communication. Instead, a session could be = resumed when new data is to be transmitted in order to re-establish the = connection state at these middleboxes without the need of performing an = entire handshake.


In addition, = when considering memory-constrained devices that interact with multiple = other devices or services (e.g., CoAP servers), ticket-based session = resumption could help maintain session state for more connections than = would actually fit into the scarce memory resources of the constrained = device. To this end, a memory-constrained device could offload the DTLS = session state (and potentially the corresponding upper layer protocol = state) to the respective communication partner and swap active = connections that occupy its scarce memory = resources.

Sorry for my prior = mis-post,
Ren=E9




=
-----Original = Message-----
From: dtls-iot [mailto:dtls-iot-bounces@ietf.org= ] On Behalf Of Zach Shelby
Sent: Friday, March 14, 2014 5:40 = AM
To: Klaus Hartke
Cc: dtls-iot@ietf.org
Subject: Re: = [Dtls-iot] Session resumption (was: [TLS] New draft: = draft-
rescorla-tls13-new-flows-01)

Hi Klaus,

I know = you're working to put together a draft on this, but I wanted = to
resurface this thread in case others have some more input for = you.

Looking our deployments and use cases for DTLS, I can't find = a use for either
renegotiation or resumption (as defined = today).

We do however have the problem of dynamic IP addresses = changing fairly
often on mobile constrained endpoints, sometimes = in-between even just
single CoAP notifications. It would be very = useful if DTLS 1.3 would have a
mechanism to deal with that without = requiring a new handshake each time
the IP address changes. Some kind = of mechanism to include the Session ID
after the IP address has = changed for example.

Zach

On Feb 25, 2014, at 6:06 AM, = Klaus Hartke <hartke@tzi.org> = wrote:

Eric Rescorla = wrote:
- There is no currently defined = support for any kind of resumption.
We need to decide if resumption = is still an important feature in
light of the trend towards more PFS = and faster processors.  I'm
particularly looking for input from = the IoT/DICE guys here.

I'm not really sure what's = being done in existing deployments, but I'd
be inclined to say that = session resumption is not really needed.

The feature allows a = client to create a session and get a Session ID.
This Session ID can = be used by the client to duplicate the session or
to later resume the = previous session. The server has to store the
session state with the = Session ID in a cache.

- Duplicate the session: I'd assume that a = constrained node typically
maintains only one session to a given = destination. For example, with
CoAP a session can be used for as many = requests as needed; CoAP does
not need a new session for every = request.

- Resume a previous session: I'm not exactly sure what a = client should
do when it has established a session but hasn't used it = for a while.
For example, if the client has created a session to make = a CoAP
request and later wants to make another request, should it = first
resume the session? Or just try to use it, get an alert, and = then
resume it? Or try to use it, get an alert, and create a new = session?
I'd say that the server either has the session state still = (then the
client should be able to make the request right away = without resuming
the session) or it doesn't (then the client has to = create a new
session).

Are there other use cases?
Are my = assumptions valid?
Am I missing something?
What's implemented in = existing IoT DTLS deployments?

Best = regards,
Klaus



---------- Forwarded message = ----------
From: Eric Rescorla <ekr@rtfm.com>
Date: 19 February = 2014 21:40
Subject: [TLS] New draft: = draft-rescorla-tls13-new-flows-01
To: "tls@ietf.org" <tls@ietf.org>


Folks,
I have prepared a new version of the TLS 1.3 flows document = which
should appear in the repository shortly and in the meantime can = be
found at:

https://github.com/tlswg/tls13-spec/blob/master/draft-rescorla-tls-1= .3
.txt

This version fleshes out a "recommended" set of = flows:

- 2-RTT where the client has no knowledge of the =  server's
capabilities.

- 1-RTT where the client knows = the server's semi-permanent  DHE/ECDHE
key pair.

- 0-RTT = where the client and the server have shared = anti-replay
state.

There are still a number of open issues, = but this should be clear
enough to see the direction I am trying to = go. These flows are
structured so that the 1-RTT case is the base = case with the 2-RTT and
0-RTT versions being variants of the basic = 1-RTT handshake. All
variants encrypt the client extensions that are = not required to define
the cryptographic processing (e.g., SNI is = encrypted but curve
negotiation is not).

I think the high = order bit here is whether we want to have encrypted
SNI, because that = dictates the position of the DHE exchanges with
respect to the = server's messages.

There are three options here:

- = Never
- Sometimes
- Always

The flows in this draft take the = position of "Always" which is simple.
"Never" is actually simpler. = "Sometimes" is the most complicated.
There are two cases where we = could shave off latency if we were
willing to disclose the SNI to = passive attackers (and in cases where
the client and server have = never talked before.) My sense of recent
discussion is that people = feel it's important to have modes that
protect SNI even if those are = not the only modes. However, that means
that if we want to have = non-SNI protecting modes, they are additional
complexity. Please let = me know if I have misread the WG here.


Here are some other = things to keep in mind as you read the document.

- Per my sense = of the list, I have totally removed static RSA.  If
people = strongly object to that, please speak up and let me know.

- There = has been no real security analysis of this material other than
at the = hand-wavy level. We clearly need that, but the first thing we
need is = to be clear on whether this is approximately the right set of
points = in the complexity/performance/privacy tradeoff space and then
make = sure that the security properties are correct. So, if you = see
something that looks wrong or even grievously wrong, don't panic = (but
do point it out).


- There is no currently defined = support for any kind of resumption.
We need to decide if resumption = is still an important feature in light
of the trend towards more PFS = and faster processors.  I'm particularly
looking for input from = the IoT/DICE guys here.

- We will probably need to work out some = of the details for DTLS, but
I wanted to get TLS nailed down = first.

- We also need to do some work on the symmetric crypto, = e.g., to make
encrypt-then-MAC the default, perhaps to deprecate some = ciphers,
compression, etc. I haven't forgotten that, but I want to = deal with
the handshakes first.

- As before, this incorporates = ideas from a lot of different people
(and many times the same idea = from different people). If you think you
should acknowledged in the = text and/or acknowledgements differently,
please let me = know.

Thanks and comments = welcome
-Ekr

_______________________________________________
= dtls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.o= rg/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/zachshel= by/


-- IMPORTANT NOTICE: The contents of this email and = any attachments are
confidential 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,
Registered in England & Wales, Company No:  2557590 = ARM Holdings plc,
Registered office 110 Fulbourn Road, Cambridge CB1 = 9NJ, Registered in
England & Wales, Company No: =  2548782

_______________________________________________
dt= ls-iot mailing list
dtls-iot@ietf.org
https://www.ietf.o= rg/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.

--
Dipl.-Inform. Rene Hummen, Ph.D. = Student
Chair of Communication and Distributed Systems
RWTH Aachen = University, Germany
tel: +49 241 80 21426
web: http://www.com= sys.rwth-aachen.de/team/rene-hummen/

= --Apple-Mail=_EAEFDC3E-5782-4556-AE4A-E7C285598257-- --Apple-Mail=_CC45B493-7790-463C-9883-AEA056DA03D8 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 AQcBMBwGCSqGSIb3DQEJBTEPFw0xNDAzMTcxMjE1MDdaMCMGCSqGSIb3DQEJBDEWBBRdlOPtA0AZ 0K6DIXmKusTRiFv17TB4BgkrBgEEAYI3EAQxazBpMF4xCzAJBgNVBAYTAkRFMRQwEgYDVQQKEwtS V1RIIEFhY2hlbjEXMBUGA1UEAxMOUldUSCBBYWNoZW4gQ0ExIDAeBgkqhkiG9w0BCQEWEWNhQHJ3 dGgtYWFjaGVuLmRlAgcUeQynpnOUMHoGCyqGSIb3DQEJEAILMWugaTBeMQswCQYDVQQGEwJERTEU MBIGA1UEChMLUldUSCBBYWNoZW4xFzAVBgNVBAMTDlJXVEggQWFjaGVuIENBMSAwHgYJKoZIhvcN AQkBFhFjYUByd3RoLWFhY2hlbi5kZQIHFHkMp6ZzlDANBgkqhkiG9w0BAQEFAASCAQB8rsIlVRB9 G2Szu7Gx27OJw4uXI3yHFH8Hp19ymIbtqkqCFIBomWAltctPye9X9r60chUVr9otvFEWbJenszhq hGtEjduvQrrQxo/lC5GE455aSIN2ieg/+EHaxCaYkOEpDXCDCeleUOPnUeSH+Dmnmm4BGgBDaMZQ /0urMKGGlKYpINp3gtvU17aDaBl2hrhd3gW8H2kmCTyzmvQUhM99WeEPd0w06jT2qZL5G4qZUjWc BXO8TRWRkWHwc/K7rV2JTVo2iXbIxHFt0223qmvyn591f26l8l0g7AHYnNTW33VnhdAJGakkB4dV CGaDsYWQeNBe6C9jxLAZr7R343ibAAAAAAAA --Apple-Mail=_CC45B493-7790-463C-9883-AEA056DA03D8-- From nobody Fri Mar 21 03:14:04 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 98EA21A06B4 for ; Fri, 21 Mar 2014 03:14:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.547] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKJaU0eawezJ for ; Fri, 21 Mar 2014 03:13:59 -0700 (PDT) Received: from fsmsg2.sics.se (fsmsg2.sics.se [IPv6:2001:6b0:3a:1:250:56ff:fea9:52ad]) by ietfa.amsl.com (Postfix) with ESMTP id 0B5F11A03B5 for ; Fri, 21 Mar 2014 03:13:58 -0700 (PDT) Received: from pps.filterd (fsmsg2 [127.0.0.1]) by fsmsg2.sics.se (8.14.5/8.14.5) with SMTP id s2LACAOc016254; Fri, 21 Mar 2014 11:13:33 +0100 Received: from letter.sics.se (letter.sics.se [193.10.64.6]) by fsmsg2.sics.se with ESMTP id 1jr6a8svw9-1; Fri, 21 Mar 2014 11:13:32 +0100 Received: from [192.168.10.86] (unknown [111.68.98.173]) (Authenticated sender: shahid@sics.se) by letter.sics.se (Postfix) with ESMTPSA id D1C9C40116; Fri, 21 Mar 2014 11:13:28 +0100 (CET) From: Shahid Raza Content-Type: multipart/alternative; boundary="Apple-Mail=_33A6A7C7-99E7-4CE5-BDA0-F7263FE9D958" Date: Fri, 21 Mar 2014 15:13:18 +0500 Message-Id: <4D6EDE04-5315-48F3-93C5-2B9E9D5625B6@sics.se> To: dtls-iot@ietf.org Mime-Version: 1.0 (Mac OS X Mail 7.2 \(1874\)) X-Mailer: Apple Mail (2.1874) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:5.11.87, 1.0.14, 0.0.0000 definitions=2014-03-21_03:2014-03-21,2014-03-21,1970-01-01 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 suspectscore=6 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=7.0.1-1402240000 definitions=main-1403210027 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/zCWV5_5mp1-KAjnHqmhbdpPshoQ Cc: Shahid Raza , "Olivier Dupont \(odupont\)" , Hossein Shafagh Subject: [Dtls-iot] New Draft Notification - [draft-raza-dice-compressed-dtls-00] X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Mar 2014 10:14:02 -0000 --Apple-Mail=_33A6A7C7-99E7-4CE5-BDA0-F7263FE9D958 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Dear All, A new draft is submitted to the DICE Working Group.=20 http://tools.ietf.org/html/draft-raza-dice-compressed-dtls-00 This work provides a lightweight CoAPs by compressing the underneath = DTLS protocol with 6LoWPAN header compression mechanisms. With DTLS = header compression we achieve energy efficiency by reducing the message = size, since communication requires more energy than computation. Also, = it avoids 6LoWPAN fragmentation that is applied when the size of = datagram is larger than the link layer MTU. Our compressed DTLS = maintains true End-to-End (E2E) security between resource constrained = hosts in 6LoWPAN networks and typical Internet hosts that use = uncompressed CoAPs. Regards Shahid --------------------------------------------------------------- Shahid Raza PhD, Senior Researcher Networked Embedded Systems group Swedish Institute of Computer Science (SICS) SICS Swedish ICT, Stockholm, Sweden Ph. No. +46 768831797 http://www.shahidraza.info Research Interests: IoT, Security, WSNs --------------------------------------------------------------- --Apple-Mail=_33A6A7C7-99E7-4CE5-BDA0-F7263FE9D958 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
Dear All,

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

Regards
Shahid

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

Research Interests: IoT, Security, = WSNs
Subject: Re: [Dtls-iot] Call for WG adoption of draft-hartke-dice-profile-03 X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Mar 2014 04:07:08 -0000 Based on the positive support for WG adoption, Dorothy and I would like the= authors to re-submit as draft-ietf-dice-profile-00. Please integrate the c= omments received in London either in this submission or latest as -01. In order for all of us to better participate, the authors should use Trac t= ickets (http://tools.ietf.org/wg/dice/trac/report/1) in order to keep tabs = on open issues or upcoming changes to the draft. We have found that useful = in the CoRE WG. Please also keep the XML source of the draft in the DICE SV= N. Thanks, Zach & Dorothy On Mar 10, 2014, at 12:21 PM, Zach Shelby wrote: > The draft draft-hartke-dice-profile-03 has made progress on our DTLS Prof= ile WG item, and had good consensus during our London meeting. This email i= s a call for confirmation of that consensus. Please respond if you support= the adoption of this document as the basis for this work item. > > If adopted the authors would of course need to take into account the feed= back received during the DICE meeting in London, and changes going forward. > >> From our charter: > > Dec 2013 - WG document for DTLS for Constrained Environments profile > > Which keeps us on track to deliver: > > May 2014 - DTLS for IoT profile specification submitted to the IESG for = publication as standards track > > 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 c= onfidential and may also be privileged. If you are not the intended recipie= nt, please notify the sender immediately and do not disclose the contents t= o any other person, use it for any purpose, or store or copy the informatio= n in any medium. Thank you. > > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Regi= stered in England & Wales, Company No: 2557590 > ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ,= Registered in England & Wales, Company No: 2548782 > > _______________________________________________ > 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 nobody Mon Mar 31 09:31:26 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 156C01A6F11 for ; Mon, 31 Mar 2014 09:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.289 X-Spam-Level: X-Spam-Status: No, score=0.289 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, FREEMAIL_FROM=0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DjpdS3JkH416 for ; Mon, 31 Mar 2014 09:31:24 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) by ietfa.amsl.com (Postfix) with ESMTP id A29D91A088C for ; Mon, 31 Mar 2014 09:31:23 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0MGB7j-1WIrY13utT-00FCT0 for ; Mon, 31 Mar 2014 18:31:19 +0200 Message-ID: <5339959A.30701@gmx.net> Date: Mon, 31 Mar 2014 18:19:38 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="J3MtAEHoFT3QvF9GgvjtLlRc7PTS7tL0p" X-Provags-ID: V03:K0:9Z1yvYP8DVB2dNShZPT1hPhK0GJ39pzAthKeOHB/Gu4xke3EBkX kKTcoMKk94hMF5V/OqTNpfT2CLojKEaJmWFXI3hEXmQNE1UwawuZeCixG+yGgHkXlWLXiFB /rPoCsK+0jdUqIfGSiO0hwYOqTHJadiNQ8vjXlY1zEV99eBVQRf84Qaa5jp0bjMLnenzs/y ctNFBRsY6eO8nyW0EY6dQ== Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/jJbOI6Ydl7lHWLL6t5KfMnf1Gvs Subject: [Dtls-iot] =?utf-8?q?draft-ietf-dice-pro=EF=AC=81le-00?= X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 16:31:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --J3MtAEHoFT3QvF9GgvjtLlRc7PTS7tL0p Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi all, I just submitted version -00 of the draft-ietf-dice-pro=EF=AC=81le docume= nt as recommended by our working group chairs. The version is a copy of the version I presented at the last IETF meeting (draft-hartke-dice-profile-03). As a next step we will take the feedback collected during the face-to-face meeting (see http://www.ietf.org/proceedings/89/minutes/minutes-89-dice) and suggest changes. In particular, there were a few items missing in the current draft write-up (as mentioned in the presentation in http://www.ietf.org/proceedings/89/slides/slides-89-dice-1.pdf). Furthermore, several participants suggested to also include a profile description for the case where the TLS server is the constrained device. Currently, the document only includes the case where the TLS client is resource limited. Ciao Hannes --J3MtAEHoFT3QvF9GgvjtLlRc7PTS7tL0p Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTOZWaAAoJEGhJURNOOiAtXzIH/0BDiEhH+LzG+9Gn7os3iixC 3J7nIHV+aw/H+rzvyxltHO5XEnyvEpyB+Hp+ex8+QBIOokX0rK10zl9rttryouFZ DXGifzuTms9heqPe0bh4IowA1cMv/8oyHCYU7+KFtx4Ip5YeNBJvj0ilk5suGqMG xoq0QLDr87TkC7uv2S8RPRskryRV8b0kM5uzQmNBuY9Y3CkB4SohbgE9j3ZI4P9f vhmP11PM/QfHE/zQpIW+uMGqXw7Mizh3xh1ny3LWoE9u6ZqPKN8EUA1F57gy8gzB jckGF2As8cxvvnqKXHNm5TRyWybzr6HYbdx77szWZYeyKoYf8o5G7NEgqF8196c= =3go5 -----END PGP SIGNATURE----- --J3MtAEHoFT3QvF9GgvjtLlRc7PTS7tL0p-- From nobody Mon Mar 31 10:32:29 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F8D01A6F05 for ; Mon, 31 Mar 2014 10:32:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3OXm9ESG7lkM for ; Mon, 31 Mar 2014 10:32:22 -0700 (PDT) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id E59D91A089B for ; Mon, 31 Mar 2014 10:32:21 -0700 (PDT) Received: from [192.168.131.137] ([80.92.119.215]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0LlpJU-1X3jll3h7w-00ZMsN; Mon, 31 Mar 2014 19:32:14 +0200 Message-ID: <5339A3AE.5060002@gmx.net> Date: Mon, 31 Mar 2014 19:19:42 +0200 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.4.0 MIME-Version: 1.0 To: Zach Shelby , "dtls-iot@ietf.org" References: <7CBD7068-03A1-4587-93D4-39D58FC1715A@arm.com> In-Reply-To: <7CBD7068-03A1-4587-93D4-39D58FC1715A@arm.com> X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="GtWHNLas4p8knkEaXDsG3VBaKcrL6qD0P" X-Provags-ID: V03:K0:UGg1r67ECPFUdIpUwHc1okRXuGsALvoCNxfUdNpN+QUt8Hx7ebw dzCOdXS9jZgAriXrIzT/b6sWlQRuEMeZP2qOFf7vdcjcdyf1QVpst7VVpsslUO6oWbCaJjX ixAdBosuMknihTN7TE/Ds53Q0GZsYg1EwXjqViA6ATPIKOpdpCvkqcZZq01uuDiJrGarEXo FckJj9rjE6MXs0+qJYtIg== Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/FWYrWyFixjMZH0lBSlSUeG72cNA Subject: Re: [Dtls-iot] draft-hartke-dice-profile-03 comments X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 17:32:25 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --GtWHNLas4p8knkEaXDsG3VBaKcrL6qD0P Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Hi Zach, thanks for the review and sorry for the late response Please find some responses inline: On 03/03/2014 11:51 AM, Zach Shelby wrote: >=20 > Here is my initial review on the draft-hartke-dice-profile-03. > Overall, I think this is an excellent start. I can already see IoT > developers cracking down cold beer and enjoying this document, it is > going to save people a lot of time and misunderstanding about DTLS in > this space. >=20 > General comments >=20 > - The text often refers to keying material being installed or updated > via firmware update. Although that could be the case for some limited > systems (or just for the purpose of bootstrapping), we are seeing key > management and more generally device management for IoT device > security configuration. We don't want to give implementers the > impression that they should be hard-coding security configurations in > firmware, as that get unmanageable quickly. We should probably talk > about "software update or security management mechanisms". For > example when this profile would be used for Lightweight M2M for > example, such security management is provided by that standard itself > over CoAP. It is probably a bit outside the space for this document to talk about how exactly the credentials get to the device (since it has nothing to do with DTLS itself). It might be better to document the assumptions instead. For example, with pre-shared secret TLS usage we assume that an identifier and a shared secret was pre-provisioned to the TLS client. I will make this change the next version of the document. >=20 > - The draft talks about only specifying Client functionality, but > then in reality there are quite a few implementation requirements on > Servers too=85 You are certainly right. The functionality the client uses has to be supported by the server since otherwise nothing works. However, what we tried to do is to balance the requirements in such a way that the TLS server has to deal with complexity and not the client (since the client is resource constrained in the current write-up). >=20 > Section 1 >=20 > "is likely to be useful for IoT scenarios as well" - Is this maybe a > little too unsure. As DTLS is required already by several standards > for IoT, it is safe to assume DTLS will be widely used for IoT. This > document is meant to make it a lot easier to use, implement and > interoperate. >=20 OK. Will fix it. > Section 2 >=20 > Some possible text to help clarify Client and Server terminology > here: >=20 > "Note that "Client" and "Server" in this document refer to TLS roles, > where the Client initiates the TLS handshake. This does not restrict > the interaction pattern of the protocols carried inside TLS as the > record layer allows bi-directional communication. In the case of CoAP > the "Client" can act as a CoAP Server or Client." Makes sense. This reflects the issues. >=20 > Section 4 >=20 > If the RFC4279 PSK identity and key length requirements are not > applicable to this profile, we probably need to define what are? I guess we cannot dictate how long they will be; we just need to point out that implementations do not require allocating a minimum length. [I should probably add that there might be cases where IoT devices have a user interface and in those cases the requirements of RFC 4279 apply.] >=20 > Section 5 >=20 > Regarding the question, the must implement cipher required by CoAP > for DTLS was chosen to align with device hardware (802.15.4 SoCs > typically have AES-CCM hardware engines) and other standards like > SE2.0 that requires that cipher. It is probably out of scope for us > to start changing that in DICE. Of course that is only the must > implement cipher suite, a DTLS implementation can support others. What to say about ciphersuites is of course a bit tricky. The desired properties seem to change quite quickly. I suspect that developers would like to receive some guidance regarding cryptographic algorithms and what their implications are. But choosing a specific algorithm might make it somewhat challenging to be meet the need of everyone. >=20 > Section 6 >=20 > The EUI-64 is not a required by CoAP for use as the Authority Name, > but is used as an example of a stable endpoint identifier. So I would > say: >=20 > "For client certificates the identifier used in the SubjectAltName or > in the CN is a stable endpoint identifier such as an EUI-64 [EUI64], > as described in Section 9.1.3.3 of [I-D.ietf-core-coap]." The problem is of course the added flexibility since the choice of the identify changes the way the authorization check is done. The CoAP protocol is somewhat open on that issue and even allows the identifier to be put into either CN or the SubjectAltName rather than mandating one specific way. In documents submitted to the ACE group I noticed that the examples showing certificates had wrong identifiers in there that, particularly in the context of server authentication, make uniqueness and the ability to perform authorization checks difficult. So, I think some guidance is useful but I will have to think about the story a bit more. >=20 > Section 10 >=20 > Regarding PFS and the chosen cipher suite, we should again probably > leave that to CoRE as implementers of course can support other cipher > suites. We could e.g. require that Servers support the > sheffer-tls-bcp recommended ciphers for interoperability with a > Client that choses to use them? >=20 The problem is that it is rather unlikely that constrained devices will implement a range of different TLS ciphersuites since it directly conflicts with the desire to keep the memory footprint small. Overall, for the question is how strongly aligned with CoAP (and the ciphersuite recommendations) we want to be. Ciao Hannes >=20 > Zach Shelby Director of Technology ARM Internet of Things BU=20 > www.arm.com mobile: +1 (408) 203-9434 Skype: zdshelby LinkedIn: > fi.linkedin.com/in/zachshelby/ >=20 >=20 > -- IMPORTANT NOTICE: The contents of this email and any attachments > are confidential 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. >=20 > ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, > Registered in England & Wales, Company No: 2557590 ARM Holdings plc, > Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in > England & Wales, Company No: 2548782 >=20 > _______________________________________________ dtls-iot mailing > list dtls-iot@ietf.org=20 > https://www.ietf.org/mailman/listinfo/dtls-iot >=20 --GtWHNLas4p8knkEaXDsG3VBaKcrL6qD0P Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBCgAGBQJTOaOuAAoJEGhJURNOOiAtNUcH/int6xC6Za051Jm+8US9bgNI +wh8LU25+q9BRW/0HUFSCrH5BrZO+NKWcwvJEUJataOCYJuQFx1m8C6iHeKvIReX xKQvxiqzk7ag5Z7wIY76FN9q5JxDxWuQQQYRBwcuD+yoV5Ow57lcchZVGA80Y/1L ktHCcLqt1hm3LzwEGrf9ZBMcTV67gInMzDa1QHLz9d5Ir1yuzKhFan8wWeaHzpCd PKYgZYG95rzvlOcHoEDuXiwBzt80hfPyeoUpXBspHnjgCG2/hpKHhQFc5VF65aEc x9z3U2QbWnK8hfRCr0o13xQdXb1qX5UJd6UoKpACNghc/iWOccuAhozHp/2/uxQ= =BiIu -----END PGP SIGNATURE----- --GtWHNLas4p8knkEaXDsG3VBaKcrL6qD0P-- From nobody Mon Mar 31 12:10:44 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA59B1A08B4; Mon, 31 Mar 2014 12:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wwu7GMuqPm0G; Mon, 31 Mar 2014 12:10:41 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 553C51A6F80; Mon, 31 Mar 2014 12:10:41 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.2.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140331191041.31628.28322.idtracker@ietfa.amsl.com> Date: Mon, 31 Mar 2014 12:10:41 -0700 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/OMvvsCIBknUDNJ4dUHQaRK86tRk Cc: dtls-iot@ietf.org Subject: [Dtls-iot] I-D Action: draft-ietf-dice-profile-00.txt X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 31 Mar 2014 19:10:43 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the DTLS In Constrained Environments Working Group of the IETF. Title : A DTLS 1.2 Profile for the Internet of Things Authors : Klaus Hartke Hannes Tschofenig Filename : draft-ietf-dice-profile-00.txt Pages : 20 Date : 2014-03-31 Abstract: This document defines a DTLS profile that is suitable for Internet of Things applications and is reasonably implementable on many constrained devices. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dice-profile/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dice-profile-00 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/