From cabo@tzi.org Sat Feb 1 01:34:36 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 B62391A1F66; Sat, 1 Feb 2014 01:34:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0OxaZxLu9Ss; Sat, 1 Feb 2014 01:34:34 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 897381A04CD; Sat, 1 Feb 2014 01:34:34 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s119YR2S000249; Sat, 1 Feb 2014 10:34:27 +0100 (CET) Received: from [192.168.217.105] (p54892C3C.dip0.t-ipconnect.de [84.137.44.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 93FC156B; Sat, 1 Feb 2014 10:34:26 +0100 (CET) From: Carsten Bormann Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Date: Sat, 1 Feb 2014 10:34:24 +0100 To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, roll WG , lwip@ietf.org Message-Id: Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) X-Mailer: Apple Mail (2.1827) Subject: [Dtls-iot] Constrained Node/Network Cluster @ IETF89, early draft version 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: Sat, 01 Feb 2014 09:34:37 -0000 A first draft version of the IETF88 agenda is out. ** THIS IS GOING TO CHANGE ** for conflict resolution,=20 so please don't make travel arrangements based on it. Here is my usual eclectic condensed agenda built from that. =20 All times are UTC (UTC-0000). The Constrained Node/Network group meetings are nicely spread out over = the week. As usual, we have one conflict with oauth (on Tuesday); since much of = the CoRE security work is moving over to ACE this is survivable (we'll = do any remaining security-related CoRE work on Friday then). Gr=FC=DFe, Carsten MONDAY, March 3, 2014 0900-1130 Morning Session I Buckingham APP appsawg Applications Area Working Group WG - = Combined with APPAREA 1300-1500 Afternoon Session I Blenheim APP httpbis Hypertext Transfer Protocol Bis WG Sovereign INT dnssd Extensions for Scalable DNS Service = Discovery WG 1520-1620 Afternoon Session II Viscount OPS eman Energy Management WG Sovereign SEC *** dice DTLS In Constrained Environments WG Palace C SEC httpauth Hypertext Transfer Protocol = Authentication WG 1630-1730 Afternoon Session III Palace C SEC httpauth Hypertext Transfer Protocol = Authentication WG TUESDAY, March 4, 2014 0900-1130 Morning Session I Park Suite APP *** core Constrained RESTful Environments WG Sovereign INT homenet Home Networking WG Palace C SEC oauth Web Authorization Protocol WG 1300-1400 Afternoon Session I Viscount INT intarea Internet Area Working Group WG 1600-1830 Afternoon Session III Viscount INT 6man IPv6 Maintenance WG Balmoral SEC tls Transport Layer Security WG Sovereign TSV rmcat RTP Media Congestion Avoidance = Techniques WG WEDNESDAY, March 5, 2014 0900-1130 Morning Session I Balmoral APP *** ace Authentication and Authorization for = Constrained Environments BOF Sovereign OPS v6ops IPv6 Operations WG 1300-1500 Afternoon Session I Blenheim APP httpbis Hypertext Transfer Protocol Bis WG Viscount TSV taps Transport Services BOF 1520-1620 Afternoon Session II Balmoral INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Buckingham RTG rtgarea Routing Area Open Meeting Blenheim TSV tsvwg Transport Area Working Group WG 1630-1730 Afternoon Session III Balmoral INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Buckingham RTG rtgarea Routing Area Open Meeting THURSDAY, March 6, 2014 0900-1130 Morning Session I Viscount TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Buckingham INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Sovereign OPS v6ops IPv6 Operations WG Viscount SEC saag Security Area Open Meeting 1520-1650 Afternoon Session II Viscount RTG *** roll Routing Over Low power and Lossy = networks WG 1700-1830 Afternoon Session III Balmoral INT *** lwig Light-Weight Implementation Guidance WG Blenheim SEC jose Javascript Object Signing and Encryption = WG FRIDAY, March 7, 2014 0900-1130 Morning Session I Richmond/Chelsea/Tower APP uta Using TLS in Applications WG Buckingham TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session 1 Buckingham APP *** core Constrained RESTful Environments WG Balmoral APP json JavaScript Object Notation WG From cabo@tzi.org Sat Feb 1 02:10:47 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 D66DA1A0532; Sat, 1 Feb 2014 02:10:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u5t_BoqUYC9Z; Sat, 1 Feb 2014 02:10:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3CE5C1A04CD; Sat, 1 Feb 2014 02:10:46 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s11AAdwS011188; Sat, 1 Feb 2014 11:10:39 +0100 (CET) Received: from [192.168.217.105] (p54892C3C.dip0.t-ipconnect.de [84.137.44.60]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8032C582; Sat, 1 Feb 2014 11:10:38 +0100 (CET) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: Date: Sat, 1 Feb 2014 11:10:36 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, roll WG , lwip@ietf.org X-Mailer: Apple Mail (2.1827) Subject: Re: [Dtls-iot] Constrained Node/Network Cluster @ IETF89, early draft version 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: Sat, 01 Feb 2014 10:10:48 -0000 On 01 Feb 2014, at 10:34, Carsten Bormann wrote: > so please don't make travel arrangements based on it. ... and it is probably worth pointing out that right after the IETF on = Friday, there will be a plugtest close to the IETF hotel. If you are = interested in the constrained node/network space, have a look and = register soon (registration is free of charge). http://www.etsi.org/news-events/events/741-plugtests-2014-coap4 (The title focuses on CoAP, but there will be some 6LoWPAN = interoperability testing as well. Pick and choose.) Gr=FC=DFe, Carsten (PS.: The 6tisch people run their own interop specifically for 6tisch = during the IETF week, but everyone involved in 6tisch already knows = that.) From SyeLoong.Keoh@glasgow.ac.uk Mon Feb 3 17:52:13 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 6CD781A01A8 for ; Mon, 3 Feb 2014 17:52:13 -0800 (PST) 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 OzN58B9iqSq5 for ; Mon, 3 Feb 2014 17:52:11 -0800 (PST) Received: from plockton.cent.gla.ac.uk (plockton.cent.gla.ac.uk [130.209.16.75]) by ietfa.amsl.com (Postfix) with ESMTP id CB7E91A012D for ; Mon, 3 Feb 2014 17:52:10 -0800 (PST) Received: from hub01.campus.gla.ac.uk ([130.209.14.19]) by plockton.cent.gla.ac.uk with esmtp (Exim 4.72) (envelope-from ) id 1WAVBJ-0000qw-UQ; Tue, 04 Feb 2014 01:52:09 +0000 Received: from cms01.campus.gla.ac.uk ([169.254.1.69]) by hub01.campus.gla.ac.uk ([130.209.14.19]) with mapi; Tue, 4 Feb 2014 01:52:09 +0000 From: Sye Loong Keoh To: Daniel Migault , "dtls-iot@ietf.org" Date: Tue, 4 Feb 2014 01:53:39 +0000 Thread-Topic: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP Thread-Index: Ac8ek4B8vkp2SN6RSzmRE6SrvqM4HwCt72KA Message-ID: References: In-Reply-To: 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 Subject: Re: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP 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, 04 Feb 2014 01:52:13 -0000 Hi Daniel, As pointed out by Hannes, DICE WG is not chartered to look at IPSec for IoT= . However, I think your draft might be useful for LWIG WG though. Cheers Sye Loong -----Original Message----- From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Daniel Migau= lt Sent: Friday, 31 January, 2014 10:48 PM To: ipsec@ietf.org; dtls-iot@ietf.org Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP Hi, Please find the two drafts we have just posted. They are about IPsec/ESP mi= nimal implementation and Diet-ESP designed for IoT. Comment are welcome! Best Regards, Daniel Name: draft-mglt-dice-diet-esp Revision: 00 Title: Diet-ESP: a flexible and compressed format for IPsec/ESP Document date: 2014-01-31 Group: Individual Submission Pages: 21 URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/ Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00 Abstract: IPsec/ESP has been designed to secure IP packets exchanged between two nodes. IPsec implements security at the IP layer which makes security transparent to the applications, as opposed to TLS or DTLS that requires application to implement TLS/DTLS. As a result, IPsec enable to define the security rules in a similar way one establishes firewall rules. One of the IPsec's drawbacks is that implementing security on a per packet basis adds overhead to each IP packet. Considering IoT devices, the data transmitted over an IP packet is expected to be rather small, and the cost of sending extra bytes is so high that IPsec/ESP can hardly be used for IoT as it is currently defined in RFC 4303. This document defines Diet-ESP, a protocol that compress and reduce the ESP overhead of IPsec/ESP so that it can fit security and energy efficient IoT requirements. Diet-ESP use already existing mechanism like IKEv2 to negotiate the compression format. Furthermore a lot of information, already existing for an IPsec Security Association, are reused to offer light negotiation in addition to maximum compression. Name: draft-mglt-lwig-minimal-esp Revision: 00 Title: Minimal ESP Document date: 2014-01-31 Group: Individual Submission Pages: 6 URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00 Abstract: This document describes a minimal version of the IP Encapsulation Security Payload (ESP) described in RFC 4303 which is part of the IPsec suite. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document does not update or modify RFC 4303, but provides a compact description of the minimal version of the protocol. If this document and RFC 4303 conflicts then RFC 4303 is the authoritative description. -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 _______________________________________________ dtls-iot mailing list dtls-iot@ietf.org https://www.ietf.org/mailman/listinfo/dtls-iot From msj@nthpermutation.com Tue Feb 4 12:23:19 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 D00F31A016D for ; Tue, 4 Feb 2014 12:23:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9IoZRYcpa66g for ; Tue, 4 Feb 2014 12:23:14 -0800 (PST) Received: from mail-qc0-f176.google.com (mail-qc0-f176.google.com [209.85.216.176]) by ietfa.amsl.com (Postfix) with ESMTP id 8D99B1A01F2 for ; Tue, 4 Feb 2014 12:23:14 -0800 (PST) Received: by mail-qc0-f176.google.com with SMTP id e16so14553628qcx.7 for ; Tue, 04 Feb 2014 12:23:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=1npm4CARYZG+hUlUXzKxUPmc84nNjS+3FGVJ2fCYQcU=; b=KcWnHfT89x7ggQzXdNNm2jRrr1420K08JJTKWYOoFdsIls/mdqXbk7WF22Gj1nHY7l CgUh9Yf01lRREsYt2Ds4hSGFr4l4TRmQ2oc7R3KyIJHoM8Y3Ex+mvvAMP70wUdE0ZfpF oqwDb7dgZLfMpVDArrJPfUHvCJNoglFzi0aNB0vm8ZRgMZ68M3VPq8bnsHYWJRVRT4Jv AV4TDn2KCWjHUpNn+HuciNUfEptt1Lt90GUA3etXKZJoMVziHcNkK3Moj5n87JA5umT4 /jCkEr+HBao2kOf0vikb+py2xQyKq8iuRQ5nVk5AhLqj4A2kiJge/ihW35w0p/K7SXel D//g== X-Gm-Message-State: ALoCoQmgFvsQKputN0FjCGMxAC/NlVCjdf4sDGpmEems2kQCwk7VKXLSgWxT0J8s+oVLZZnPcGgZ X-Received: by 10.140.96.202 with SMTP id k68mr66233662qge.84.1391545394013; Tue, 04 Feb 2014 12:23:14 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id f10sm69961449qar.12.2014.02.04.12.23.13 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 04 Feb 2014 12:23:13 -0800 (PST) Message-ID: <52F14C3A.5010300@nthpermutation.com> Date: Tue, 04 Feb 2014 15:23:22 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <20140117154946.15064.70031.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-03.txt 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, 04 Feb 2014 20:23:20 -0000 I've read through all of the versions of this document a number of times and I don't think its progressing in a useful direction as of yet. Some of this I've said before, but bear with me. 1 - Application use cases do not translate to DTLS multicast: Section 2.1 of the document has basically four use cases, which actually seem to reduce down to one or possibly two actual use cases: A control function and in information retrieval function - the light control, the parameter update and the firmware update are all control functions (albeit with differing latency requirements), the commissioning function seems to be more of of "anyone home" or something similar to what happens when you ARP for a broadcast address on a subnet. DTLS multicast appears to assume a single symmetric key per application without regard to the number of nodes in the multicast mesh. But since the key is widely possessed, there is no useful approach to using that key for sender authentication as anyone who possesses that key can spoof being anyone else. In the control use cases, what you actually want is a strong and authenticated divide between those nodes that are controllers and those nodes that are being controlled. A more appropriate combination of protocols would be a multicast L3/L4 (udp over IP multicast) for package distribution, and a digital signature L5 wrapped around the application data. For something larger, like firmware, an even more appropriate combination may be a unicast L3/L4 with an L5 multicast application which is responsible for verifying the package and its parts before redistributing them to its neighbors. (NOTE WELL - this might not be COAP). Even something like large application packages like firmware can be managed by sending out a signed table of hashes where each hash covers a portion of the firmware and where the hash can be used to verify received firmware segments before re-broadcasting them. Section 2.2.h hints at using public key as part of DTLS - but then suggests it's too expensive an approach. I think we need to get past this constant "I'm too small for public keys" argument and just say that public key technology is going to be needed even in the smallest devices. I'm sure that costs will come down sharply and quickly. I'm finding it hard to see how the use cases in the document argue at all for a DTLS multicast. 2 - "Two can keep a secret if one is dead" - Or "As the number of entities that know a secret increase, the probability of that secret being secret approaches zero". The systems that have successfully used secured multicast in the past have either been closed systems within a broader security perimeter (e.g. US DOD's Simnet testbed) or small collections of nodes with identical security domains with reasonable physical security (e.g. networked bridge sensors, earthquake sensors). Section 2.2 suggests that DTLS multicast needs to scale up to 255 senders and up to 5000 listeners, but it's probable (approaching unity) that a system of that size would be trivial to compromise, especially with the assumption that the nodes of the multicast mesh would be made up of devices or implementations from widely varying providers with widely varying skillsets and implementation rigor. Mitigations in the form of hardware security are possible, but that probably defeats the base purpose of making things work for low powered devices. 3 - The need for source authentication is hand waved, rather than analyzed. Section 2.2.h suggests that "source authentication is not a critical function to be always enabled in every LLN use case". But the use cases from 2.1, with the sole possible exception of the commissioning case (and it's unclear it's an exception) are "control" cases where it's necessary for a node to know who's telling it to do what. Instead of just throwing this to the side, the discussion on source authentication needs to be brought to front and center and the combinations worked through and then matched to the use cases. Of all the issues with this document, I believe this one to be fatal and would argue against adoption as a WG item without resolving this. 4 - The need for encryption is assumed, without any actual analysis being done (Section 2.2. d). Basically, there is a cost for confidentiality, that should be measured against need and threat. Confidentiality may be needed for responses to prompts for information, but that suggests that the inbounds response is actually unicast DTLS rather than multicast DTLS. For control multicast, it's unclear why it's important to encrypt "turn off the lights". Again, commissioning may be an exception, but please see item 2 above - is it really a secret when shared with 1000s of devices? 5 - There are mis-statements of the protections provided: Section 4.4, third para:"this guarantees that no one has spoofed the SenderID, as it protected by the MAC". Any node that has the sending key can trivially forge this message and set the SenderID to any value desired. There is a trivial attack related to this which is for an attacker to send out a valid message but with a max sequence number (and for all known senderIDs). That would prevent further use of that particular key and sender. Windowing may help, but all it does is slow down the attack. ____________________________________________ A general security principle is that symmetric keys should be only shared between at most two entities, and that private asymmetric keys should be only known to one entity. Those are guidelines, not hard rules, but there has to be substantial benefit for violating them, and a reasonable expectation that at least *some* residual security is possible. This document doesn't describe sufficient benefits to warrant violating them, and the mechanisms described lack sufficient residual security assuming your scaling numbers. I'm not looking for perfect security, but I would really prefer something that won't be broken before it's deployed. Mike On 1/17/2014 10:54 AM, Kumar, Sandeep wrote: > Dear Dice members > > A new version of the "DTLS-based Multicast Security" draft has been uploaded. The new version takes into consideration the constructive comments received during the DICE meeting in Vancouver, comments on the list and privately. > > Comments on the new version are welcome. > > Kind regards > Sandeep > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, January 17, 2014 4:50 PM > To: Kumar, Sandeep; Garcia Morchon, Oscar; Kumar, Sandeep; Sye Loong Keoh; Dijk, Esko; Garcia Morchon, Oscar; Dijk, Esko; Sye Loong Keoh > Subject: New Version Notification for draft-keoh-dice-multicast-security-03.txt > > > A new version of I-D, draft-keoh-dice-multicast-security-03.txt > has been successfully submitted by Sandeep S. Kumar and posted to the IETF repository. > > Name: draft-keoh-dice-multicast-security > Revision: 03 > Title: DTLS-based Multicast Security for Low-Power and Lossy Networks (LLNs) > Document date: 2014-01-17 > Group: Individual Submission > Pages: 19 > URL: http://www.ietf.org/internet-drafts/draft-keoh-dice-multicast-security-03.txt > Status: https://datatracker.ietf.org/doc/draft-keoh-dice-multicast-security/ > Htmlized: http://tools.ietf.org/html/draft-keoh-dice-multicast-security-03 > Diff: http://www.ietf.org/rfcdiff?url2=draft-keoh-dice-multicast-security-03 > > Abstract: > The CoAP and 6LoWPAN standards are fast emerging as the de-facto > protocols in the area of resource-constrained devices. Such IP-based > systems are foreseen to be used for building and lighting control > systems where wireless devices interconnect with each other, forming > low-power and lossy networks (LLNs). Both multicast and its security > are key needs in these networks. This draft presents a method for > securing IPv6 multicast communication in LLNs based on the DTLS which > is already present for unicast in these CoAP devices. This draft > deals with the adaptation of the DTLS record layer to protect > multicast group communication, assuming that all group members > already have the group security association parameters in their > possession. The adapted DTLS record layer provides message > confidentiality, integrity and replay protection to group messages > using the group keying material before sending the message via IPv6 > multicast to the group. > > > > > 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. > > The IETF Secretariat > > > ________________________________ > 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. > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot From Akbar.Rahman@interdigital.com Wed Feb 5 09:42: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 4E6571A01CE for ; Wed, 5 Feb 2014 09:42:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.435 X-Spam-Level: X-Spam-Status: No, score=-2.435 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.535] 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 SEpFwEAmuXxj for ; Wed, 5 Feb 2014 09:42:53 -0800 (PST) Received: from smtp-in1.interdigital.com (smtp-in1.interdigital.com [64.208.228.133]) by ietfa.amsl.com (Postfix) with ESMTP id D273E1A0122 for ; Wed, 5 Feb 2014 09:42:52 -0800 (PST) X-ASG-Debug-ID: 1391622150-06daaa7ce8461b0001-roOjxa Received: from smtp-out1.interdigital.com (sahara.interdigital.com [10.0.128.27]) by smtp-in1.interdigital.com with ESMTP id I412nwBacs7u3wkl for ; Wed, 05 Feb 2014 12:42:30 -0500 (EST) 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, 5 Feb 2014 12:43:06 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Date: Wed, 5 Feb 2014 12:43:05 -0500 X-ASG-Orig-Subj: FW: New Version Notification for draft-keoh-dice-multicast-security-04.txt Message-ID: In-Reply-To: <20140205173009.26648.99810.idtracker@ietfa.amsl.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: New Version Notification for draft-keoh-dice-multicast-security-04.txt Thread-Index: Ac8imBk8Alp3k4+mSr6MZ4QqnYsJMgAAFGtQ References: <20140205173009.26648.99810.idtracker@ietfa.amsl.com> From: "Rahman, Akbar" To: X-OriginalArrivalTime: 05 Feb 2014 17:43:06.0733 (UTC) FILETIME=[BA4309D0:01CF2299] X-Barracuda-Connect: sahara.interdigital.com[10.0.128.27] X-Barracuda-Start-Time: 1391622150 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.2.144869 Rule breakdown below pts rule name description ---- ---------------------- -------------------------------------------------- Subject: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-04.txt 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, 05 Feb 2014 17:42:55 -0000 SGkgQWxsLA0KDQoNCldlIGhhdmUgc3VibWl0dGVkIGEgbmV3IHZlcnNpb24gb2YgdGhlICJEVExT LWJhc2VkIE11bHRpY2FzdCBTZWN1cml0eSIgZHJhZnQuICAgDQoNCmh0dHA6Ly90b29scy5pZXRm Lm9yZy9odG1sL2RyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDQNCg0KDQpUaGlz IHZlcnNpb24gZG9lcyBub3QgeWV0IGFkZHJlc3MgdGhlIHZhbHVhYmxlIGNvbW1lbnRzIGZyb20g TWljaGFlbCBTdEpvaG5zLiAgV2UgYXJlIHN0aWxsIGFuYWx5emluZyBNaWNoYWVsJ3MgY29tbWVu dHMgYW5kIHdpbGwgYXR0ZW1wdCB0byByZXNwb25kIHRvIHRoZW0gYXMgc29vbiBhcyBwb3NzaWJs ZS4NCg0KDQpUaGUgY2hhbmdlcyBpbiB0aGlzIHZlcnNpb24gb2YgdGhlIGRyYWZ0IGFyZSBhcyBm b2xsb3dzLg0KDQpDaGFuZ2VzIGZyb20ga2VvaC0wMyB0byBrZW9oLTA0Og0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICBvICBBZGRlZCBkZXNjcmlwdGlvbiBv ZiBQcm94eSBvcGVyYXRpb24gaW4gYSBEVExTLWJhc2VkIG11bHRpY2FzdA0KICAgICAgc2NlbmFy aW8gaW4gU2VjdGlvbiA0LjUgKFByb3h5IE9wZXJhdGlvbikuDQoNCiAgIG8gIENvcnJlY3RlZCB0 ZXh0IGluIFNlY3Rpb24gMi4yIChTZWN1cml0eSBSZXF1aXJlbWVudHMpLCBpdGVtICJoIiwNCiAg ICAgIHRvIGluZGljYXRlIHRoYXQgbXVsdGljYXN0IHNvdXJjZSBhdXRoZW50aWNhdGlvbiBpcyBu b3Qgc3BlY2lmaWVkDQogICAgICBpbiB0aGlzIHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KDQogICBv ICBDbGFyaWZpZWQgdGhhdCBkcmFmdCBpcyB3cml0dGVuIHByaW1hcmlseSBmb3Igc2VjdXJpbmcg b2YgQ29BUA0KICAgICAgYmFzZWQgZ3JvdXAgY29tbXVuaWNhdGlvbiwgYnV0IHRoYXQgb3RoZXIg cHJvdG9jb2xzIG1heSBhbHNvIGJlDQogICAgICBzdXBwb3J0ZWQgaWYgdGhleSBoYXZlIHNpbWls YXIgY2hhcmFjdGVyaXN0aWNzLiAgU2VlIFNlY3Rpb24gMQ0KICAgICAgKEludHJvZHVjdGlvbiku DQoNCiAgIG8gIFJhbiBJRVRGIHNwZWxsIGNoZWNrZXIgYW5kIElELU5pdHMgdG9vbHMgYW5kIGNv cnJlY3RlZCB2YXJpb3VzDQogICAgICBpc3N1ZXMgdGhyb3VnaG91dCB0aGUgZG9jdW1lbnQuDQoN CiAgIG8gIFZhcmlvdXMgZWRpdG9yaWFsIHVwZGF0ZXMuDQoNCg0KDQoNCkJlc3QgUmVnYXJkcywN Cg0KDQpBa2Jhcg0KDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IGludGVy bmV0LWRyYWZ0c0BpZXRmLm9yZyBbbWFpbHRvOmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZ10gDQpT ZW50OiBXZWRuZXNkYXksIEZlYnJ1YXJ5IDA1LCAyMDE0IDEyOjMwIFBNDQpUbzogU2FuZGVlcCBL dW1hcjsgT3NjYXIgR2FyY2lhLU1vcmNob247IFNhbmRlZXAgUy4gS3VtYXI7IFN5ZSBMb29uZyBL ZW9oOyBFc2tvIERpams7IE9zY2FyIEdhcmNpYS1Nb3JjaG9uOyBFc2tvIERpams7IFJhaG1hbiwg QWtiYXI7IFN5ZSBMb29uZyBLZW9oOyBSYWhtYW4sIEFrYmFyDQpTdWJqZWN0OiBOZXcgVmVyc2lv biBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDQu dHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qt c2VjdXJpdHktMDQudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEFrYmFy IFJhaG1hbiBhbmQgcG9zdGVkIHRvIHRoZSBJRVRGIHJlcG9zaXRvcnkuDQoNCk5hbWU6CQlkcmFm dC1rZW9oLWRpY2UtbXVsdGljYXN0LXNlY3VyaXR5DQpSZXZpc2lvbjoJMDQNClRpdGxlOgkJRFRM Uy1iYXNlZCBNdWx0aWNhc3QgU2VjdXJpdHkgZm9yIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29y a3MgKExMTnMpDQpEb2N1bWVudCBkYXRlOgkyMDE0LTAyLTA1DQpHcm91cDoJCUluZGl2aWR1YWwg U3VibWlzc2lvbg0KUGFnZXM6CQkyMQ0KVVJMOiAgICAgICAgICAgIGh0dHA6Ly93d3cuaWV0Zi5v cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDQu dHh0DQpTdGF0dXM6ICAgICAgICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQta2VvaC1kaWNlLW11bHRpY2FzdC1zZWN1cml0eS8NCkh0bWxpemVkOiAgICAgICBodHRwOi8v dG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1rZW9oLWRpY2UtbXVsdGljYXN0LXNlY3VyaXR5LTA0 DQpEaWZmOiAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9ZHJhZnQt a2VvaC1kaWNlLW11bHRpY2FzdC1zZWN1cml0eS0wNA0KDQpBYnN0cmFjdDoNCiAgIFRoZSBDb0FQ IGFuZCA2TG9XUEFOIHN0YW5kYXJkcyBhcmUgZmFzdCBlbWVyZ2luZyBhcyBrZXkgcHJvdG9jb2xz IGluDQogICB0aGUgYXJlYSBvZiByZXNvdXJjZS1jb25zdHJhaW5lZCBkZXZpY2VzLiAgU3VjaCBJ UC1iYXNlZCBzeXN0ZW1zIGFyZQ0KICAgZm9yZXNlZW4gdG8gYmUgdXNlZCBmb3IgYnVpbGRpbmcg YW5kIGxpZ2h0aW5nIGNvbnRyb2wgc3lzdGVtcyB3aGVyZQ0KICAgd2lyZWxlc3MgZGV2aWNlcyBp bnRlcmNvbm5lY3Qgd2l0aCBlYWNoIG90aGVyLCBmb3JtaW5nIGxvdy1wb3dlciBhbmQNCiAgIGxv c3N5IG5ldHdvcmtzIChMTE5zKS4gIEJvdGggbXVsdGljYXN0IGFuZCBpdHMgc2VjdXJpdHkgYXJl IGtleSBuZWVkcw0KICAgaW4gdGhlc2UgbmV0d29ya3MuICBUaGlzIGRyYWZ0IHByZXNlbnRzIGEg bWV0aG9kIGZvciBzZWN1cmluZyBJUHY2DQogICBtdWx0aWNhc3QgY29tbXVuaWNhdGlvbiBpbiBM TE5zIGJhc2VkIG9uIHRoZSBEVExTIHdoaWNoIGlzIGFscmVhZHkNCiAgIHN1cHBvcnRlZCBmb3Ig dW5pY2FzdCBjb21tdW5pY2F0aW9uIGZvciBDb0FQIGRldmljZXMuICBUaGlzIGRyYWZ0DQogICBk ZWFscyB3aXRoIHRoZSBhZGFwdGF0aW9uIG9mIHRoZSBEVExTIHJlY29yZCBsYXllciB0byBwcm90 ZWN0DQogICBtdWx0aWNhc3QgZ3JvdXAgY29tbXVuaWNhdGlvbiwgYXNzdW1pbmcgdGhhdCBhbGwg Z3JvdXAgbWVtYmVycw0KICAgYWxyZWFkeSBoYXZlIHRoZSBncm91cCBzZWN1cml0eSBhc3NvY2lh dGlvbiBwYXJhbWV0ZXJzIGluIHRoZWlyDQogICBwb3NzZXNzaW9uLiAgVGhlIGFkYXB0ZWQgRFRM UyByZWNvcmQgbGF5ZXIgcHJvdmlkZXMgbWVzc2FnZQ0KICAgY29uZmlkZW50aWFsaXR5LCBpbnRl Z3JpdHkgYW5kIHJlcGxheSBwcm90ZWN0aW9uIHRvIGdyb3VwIG1lc3NhZ2VzDQogICB1c2luZyB0 aGUgZ3JvdXAga2V5aW5nIG1hdGVyaWFsIGJlZm9yZSBzZW5kaW5nIHRoZSBtZXNzYWdlIHZpYSBJ UHY2DQogICBtdWx0aWNhc3QgdG8gdGhlIGdyb3VwLg0KDQogICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBtaW51dGVz IGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBh bmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQpUaGUgSUVURiBTZWNy ZXRhcmlhdA0KDQo= From cabo@tzi.org Fri Feb 7 15:08:46 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 2A24F1AD73E; Fri, 7 Feb 2014 15:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JF3_k9F2H1dD; Fri, 7 Feb 2014 15:08:44 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 3A0B21A0444; Fri, 7 Feb 2014 15:08:44 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s17N8fN3014186; Sat, 8 Feb 2014 00:08:42 +0100 (CET) Received: from [192.168.217.105] (p54893711.dip0.t-ipconnect.de [84.137.55.17]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8EE04CF1; Sat, 8 Feb 2014 00:08:40 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: Date: Sat, 8 Feb 2014 00:08:38 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <0E66B5C7-0323-48D6-86A1-950CA260B475@tzi.org> References: To: dtls-iot@ietf.org, core , ace@ietf.org, "6lo@ietf.org WG" <6lo@ietf.org>, roll WG , lwip@ietf.org X-Mailer: Apple Mail (2.1827) Subject: [Dtls-iot] Constrained Node/Network Cluster @ IETF89, "final" version 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, 07 Feb 2014 23:08:46 -0000 On 01 Feb 2014, at 10:34, Carsten Bormann wrote: > A first draft version of the IETF88 agenda is out. > ** THIS IS GOING TO CHANGE ** for conflict resolution,=20 > so please don't make travel arrangements based on it. >=20 > Here is my usual eclectic condensed agenda built from that. =20 > All times are UTC (UTC-0000). > The Constrained Node/Network group meetings are nicely spread out over = the week. Here is an update with the =93final=94 agenda (caveat viator). Nothing of substance has changed, a couple of room assignments (and a = longer break on Tuesday). Just making sure you don=92t turn up in the wrong room... Gr=FC=DFe, Carsten MONDAY, March 3, 2014 0900-1130 Morning Session I Buckingham APP appsawg Applications Area Working Group WG - = Combined with APPAREA 1300-1500 Afternoon Session I Blenheim APP httpbis Hypertext Transfer Protocol Bis WG Sovereign INT dnssd Extensions for Scalable DNS Service = Discovery WG 1520-1620 Afternoon Session II Viscount OPS eman Energy Management WG Sovereign SEC *** dice DTLS In Constrained Environments WG Palace C SEC httpauth Hypertext Transfer Protocol = Authentication WG 1630-1730 Afternoon Session III Palace C SEC httpauth Hypertext Transfer Protocol = Authentication WG TUESDAY, March 4, 2014 0900-1130 Morning Session I Park Suite APP *** core Constrained RESTful Environments WG Sovereign INT homenet Home Networking WG Palace C SEC oauth Web Authorization Protocol WG 1300-1400 Afternoon Session I Viscount INT intarea Internet Area Working Group WG 1610-1840 Afternoon Session III Viscount INT 6man IPv6 Maintenance WG Balmoral SEC tls Transport Layer Security WG Sovereign TSV rmcat RTP Media Congestion Avoidance = Techniques WG WEDNESDAY, March 5, 2014 0900-1130 Morning Session I Balmoral APP *** ace Authentication and Authorization for = Constrained Environments BOF Sovereign OPS v6ops IPv6 Operations WG 1300-1500 Afternoon Session I Blenheim APP httpbis Hypertext Transfer Protocol Bis WG Viscount TSV taps Transport Services BOF 1520-1620 Afternoon Session II Balmoral INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Buckingham RTG rtgarea Routing Area Open Meeting Viscount TSV tsvwg Transport Area Working Group WG 1630-1730 Afternoon Session III Balmoral INT *** 6lo IPv6 over Networks of = Resource-constrained Nodes WG Buckingham RTG rtgarea Routing Area Open Meeting THURSDAY, March 6, 2014 0900-1130 Morning Session I Viscount TSV tsvarea Transport Area Open Meeting 1300-1500 Afternoon Session I Buckingham INT *** 6tisch IPv6 over the TSCH mode of IEEE = 802.15.4e WG Sovereign OPS v6ops IPv6 Operations WG Viscount SEC saag Security Area Open Meeting 1520-1650 Afternoon Session II Viscount RTG *** roll Routing Over Low power and Lossy = networks WG 1700-1830 Afternoon Session III Balmoral INT *** lwig Light-Weight Implementation Guidance WG Blenheim SEC jose Javascript Object Signing and Encryption = WG FRIDAY, March 7, 2014 0900-1130 Morning Session I Richm_Chl_Tow APP uta Using TLS in Applications WG Buckingham TSV tsvwg Transport Area Working Group WG 1150-1320 Afternoon Session 1 Viscount APP *** core Constrained RESTful Environments WG Balmoral APP json JavaScript Object Notation WG From msj@nthpermutation.com Tue Feb 11 20:49:09 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 E68421A0842 for ; Tue, 11 Feb 2014 20:49:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.7 X-Spam-Level: X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RCZd_w2M_koQ for ; Tue, 11 Feb 2014 20:49:06 -0800 (PST) Received: from mail-qc0-f182.google.com (mail-qc0-f182.google.com [209.85.216.182]) by ietfa.amsl.com (Postfix) with ESMTP id 39EAF1A0841 for ; Tue, 11 Feb 2014 20:49:06 -0800 (PST) Received: by mail-qc0-f182.google.com with SMTP id c9so14379269qcz.41 for ; Tue, 11 Feb 2014 20:49:05 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:content-type; bh=7SCnea7KTu9n1zhrD8EUDs45Op5EQsYvIDGhCXa/OjM=; b=QmhP+6vqegz5Unw//uDBP7qs13UfupyGiLS0gnM3paFPPqxTDE+I2MUoCecBXvJLeg p8xdxq6xla8iD867NOHsVszutvW3elwynDbRFdPvtQ4POWejt72oQ+XrnCHMeabqeEXs HUHbTh/9Vsdd2yPMaonKVBlLxEJIkE+pgclGhpV+t76sFH2W1TkjodqO0jo0syQYp2Gm jNLZNuOR8COlbJSighpEUd0t+XGLR7B4V4wHR9MDE00NEpOBOhg6jgy5qOsKZBqvNHd0 PCRT0YwAZOF0aJCSvbLyMxeDkUU4ZCjbvAPFS0qKxx1/+DKMZvonufXRE85GE2y7jnAa zWsg== X-Gm-Message-State: ALoCoQnl1TeXAFG5mdhZv3rU2nC8t4PLN/HOTvajA6AsdHov7bwgs6QbVLV7uerusE9UFNEVm0/D X-Received: by 10.140.96.202 with SMTP id k68mr60834493qge.84.1392180545428; Tue, 11 Feb 2014 20:49:05 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id b30sm32115167qge.21.2014.02.11.20.49.04 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 11 Feb 2014 20:49:05 -0800 (PST) Message-ID: <52FAFD52.2060907@nthpermutation.com> Date: Tue, 11 Feb 2014 23:49:22 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "dtls-iot@ietf.org" Content-Type: multipart/alternative; boundary="------------090307060805020809070803" Subject: [Dtls-iot] Compromise numbers for multicast 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 Feb 2014 04:49:09 -0000 This is a multi-part message in MIME format. --------------090307060805020809070803 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I was trying to figure out a way of expressing the issues with shared group symmetric key multicast security and the dangers of not properly constraining the size of the multicast group that shares a single key. I came up with the table below. The following table is read with the number of nodes down along the left side, and the probability of any one given node being "compromisable" running along the top. The intersection is the probability of the multicast mesh being compromised. The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a given node being compromisable. For the IOT constrained node model, I'm generally considering a node compromisable if it is physically accessible to an attacker. It *may* also be compromisable if its accessible via RF (e.g. stack smashing attacks etc). The compromise I care about is an extraction attack on the group key as that gives an attacker the ability to masquerade as any node in the mesh, eavesdrop on any traffic, and insert traffic at will. So in a mesh of 250 nodes, if there's a .1% chance that any given node is compromisable, the probability of a mesh compromise is 22.13%. But I would guess that the per node percentage will probably be closer to 1% or greater given the wide set of devices, protections and implementation strategies. This is no better than a swag, and it's hard to characterize the per node probability of compromise given the vast scope of IOT and the huge possible difference between the least and most capable nodes in a multicast group. That said, taking 1% probability of mesh compromise as an arbitrary acceptable high water mark and .01% as an arbitrary Pnode, I wouldn't use shared key multicast security for anything over a group of 100 nodes and that only for low sensitivity applications. If we're talking a Pnode of .1%, that falls to about 10 nodes. With a Pnode of 1%, that falls to about 2 nodes. The mitigations for these (physically separate network, hardware security module, physical protections) are mostly not going to be available for constrained nodes, and the effective Pnode for the whole mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue). Mike 5.000000% 1.000000% 0.100000% 0.010000% 0.001000% 5 22.62% 4.90% 0.50% 0.05% 0.00% 20 64.15% 18.21% 1.98% 0.20% 0.02% 100 99.41% 63.40% 9.52% 1.00% 0.10% 250 100.00% 91.89% 22.13% 2.47% 0.25% 500 100.00% 99.34% 39.36% 4.88% 0.50% 1000 100.00% 100.00% 63.23% 9.52% 1.00% 2500 100.00% 100.00% 91.80% 22.12% 2.47% 5000 100.00% 100.00% 99.33% 39.35% 4.88% 10000 100.00% 100.00% 100.00% 63.21% 9.52% --------------090307060805020809070803 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I was trying to figure out a way of expressing the issues with shared group symmetric key multicast security and the dangers of not properly constraining the size of the multicast group that shares a single key.  I came up with the table below.

The following  table is read with the number of nodes down along the left side, and the probability of any one given node being "compromisable" running along the top.  The intersection is the probability of the multicast mesh being compromised.

The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a given node being compromisable.

For the IOT constrained node model, I'm generally considering a node compromisable if it is physically accessible to an attacker.  It *may* also be compromisable if its accessible via RF (e.g. stack smashing attacks etc).  The compromise I care about is an extraction attack on the group key as that gives an attacker the ability to masquerade as any node in the mesh, eavesdrop on any traffic, and insert traffic at will.

So in a mesh of 250 nodes, if there's a .1% chance that any given node is compromisable, the probability of a mesh compromise is 22.13%.  But I would guess that the per node percentage will probably be closer to 1% or greater given the wide set of devices, protections and implementation strategies.

This is no better than a swag, and it's hard to characterize the per node probability of compromise given the vast scope of IOT and the huge possible difference between the least and most capable nodes in a multicast group.  That said, taking 1% probability of mesh compromise as an arbitrary acceptable high water mark and .01% as an arbitrary Pnode, I wouldn't use shared key multicast security for anything over a group of 100 nodes and that only for low sensitivity applications.  If we're talking a Pnode of .1%, that falls to about 10 nodes.  With a Pnode of 1%, that falls to about 2 nodes.

The mitigations for these (physically separate network, hardware security module, physical protections) are mostly not going to be available for constrained nodes, and the effective Pnode for the whole mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue).

Mike




  5.000000% 1.000000% 0.100000% 0.010000% 0.001000%
5 22.62% 4.90% 0.50% 0.05% 0.00%
20 64.15% 18.21% 1.98% 0.20% 0.02%
100 99.41% 63.40% 9.52% 1.00% 0.10%
250 100.00% 91.89% 22.13% 2.47% 0.25%
500 100.00% 99.34% 39.36% 4.88% 0.50%
1000 100.00% 100.00% 63.23% 9.52% 1.00%
2500 100.00% 100.00% 91.80% 22.12% 2.47%
5000 100.00% 100.00% 99.33% 39.35% 4.88%
10000 100.00% 100.00% 100.00% 63.21% 9.52%









--------------090307060805020809070803-- From sandeep.kumar@philips.com Thu Feb 13 05:51:00 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 6EAC01A0259 for ; Thu, 13 Feb 2014 05:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.499 X-Spam-Level: X-Spam-Status: No, score=-1.499 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, 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 gGl4KrKZZxcX for ; Thu, 13 Feb 2014 05:50:56 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe002.messaging.microsoft.com [65.55.88.12]) by ietfa.amsl.com (Postfix) with ESMTP id 8C0F01A01CF for ; Thu, 13 Feb 2014 05:50:56 -0800 (PST) Received: from mail44-tx2-R.bigfish.com (10.9.14.236) by TX2EHSOBE001.bigfish.com (10.9.40.21) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 13:50:55 +0000 Received: from mail44-tx2 (localhost [127.0.0.1]) by mail44-tx2-R.bigfish.com (Postfix) with ESMTP id 5B0751A0244; Thu, 13 Feb 2014 13:50:55 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -27 X-BigFish: VPS-27(zz15d6O9371Ic85fhe0eah9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received: from mail44-tx2 (localhost.localdomain [127.0.0.1]) by mail44-tx2 (MessageSwitch) id 1392299452659686_12334; Thu, 13 Feb 2014 13:50:52 +0000 (UTC) Received: from TX2EHSMHS021.bigfish.com (unknown [10.9.14.241]) by mail44-tx2.bigfish.com (Postfix) with ESMTP id 899FE440079; Thu, 13 Feb 2014 13:50:52 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS021.bigfish.com (10.9.99.121) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 13:50:52 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.200]) by 011-DB3MMR1-002.MGDPHG.emi.philips.com ([10.128.28.52]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 13:49:39 +0000 From: "Kumar, Sandeep" To: Michael StJohns , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Compromise numbers for multicast Thread-Index: AQHPJ63G//94FoEpxUCFJ03s4UqMxZqzNGxg Date: Thu, 13 Feb 2014 13:49:38 +0000 Message-ID: References: <52FAFD52.2060907@nthpermutation.com> In-Reply-To: <52FAFD52.2060907@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E525C2C011DB3MPN1025MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 13:51:00 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E525C2C011DB3MPN1025MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Mike A good characterization of the inherent difficulty of enabling multicast se= curity. Even assuming that the multicast security was based on public keys = in a multiple sender group, which is often the case in IoT, then based on y= our Pnode of .1%, a group with 10 senders with private key has a 1% mesh p= robability compromise (it is enough to compromise any one of the senders). = Considering that public-key based crypto is much more side-channel leaky a= nd often hard for developers to get it right compared to directly using the= AES co-processor available in most 802.15.4 chips, the Pnode probability i= s going to be much more higher. Like every building block, the risks associated with compromise of a node = need to be taken carefully into account, especially with multicast that ris= k goes exponentially as you show. Therefore as you mention a limit to group= sizes and additional mitigations need to be in place. Public key in itself= will not provide that mitigation, it may actually worsen the situation by = making DoS easier by tying up constrained devices in heavy computation. One= has to look at the deployment scenario, perform a risk analysis identifyin= g the threats, and make a solid design to eliminate those risks. Although y= ou are right and one should not use this building block in all deployments/= use cases, we also firmly believe that the current approach can be an effec= tive building block for reducing risks in many practical scenarios. Other c= omplementary solutions may need to be created and one solution is not going= to solve all problems. Regards Sandeep , Sye, Oscar From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Michael StJo= hns Sent: Wednesday, February 12, 2014 5:49 AM To: dtls-iot@ietf.org Subject: [Dtls-iot] Compromise numbers for multicast I was trying to figure out a way of expressing the issues with shared group= symmetric key multicast security and the dangers of not properly constrain= ing the size of the multicast group that shares a single key. I came up wi= th the table below. The following table is read with the number of nodes down along the left s= ide, and the probability of any one given node being "compromisable" runnin= g along the top. The intersection is the probability of the multicast mesh= being compromised. The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a g= iven node being compromisable. For the IOT constrained node model, I'm generally considering a node compro= misable if it is physically accessible to an attacker. It *may* also be co= mpromisable if its accessible via RF (e.g. stack smashing attacks etc). Th= e compromise I care about is an extraction attack on the group key as that = gives an attacker the ability to masquerade as any node in the mesh, eavesd= rop on any traffic, and insert traffic at will. So in a mesh of 250 nodes, if there's a .1% chance that any given node is c= ompromisable, the probability of a mesh compromise is 22.13%. But I would = guess that the per node percentage will probably be closer to 1% or greater= given the wide set of devices, protections and implementation strategies. This is no better than a swag, and it's hard to characterize the per node p= robability of compromise given the vast scope of IOT and the huge possible = difference between the least and most capable nodes in a multicast group. = That said, taking 1% probability of mesh compromise as an arbitrary accepta= ble high water mark and .01% as an arbitrary Pnode, I wouldn't use shared k= ey multicast security for anything over a group of 100 nodes and that only = for low sensitivity applications. If we're talking a Pnode of .1%, that fa= lls to about 10 nodes. With a Pnode of 1%, that falls to about 2 nodes. The mitigations for these (physically separate network, hardware security m= odule, physical protections) are mostly not going to be available for const= rained nodes, and the effective Pnode for the whole mesh is the MIN() of al= l of the Pnode's of the mesh (weakest link issue). Mike 5.000000% 1.000000% 0.100000% 0.010000% 0.001000% 5 22.62% 4.90% 0.50% 0.05% 0.00% 20 64.15% 18.21% 1.98% 0.20% 0.02% 100 99.41% 63.40% 9.52% 1.00% 0.10% 250 100.00% 91.89% 22.13% 2.47% 0.25% 500 100.00% 99.34% 39.36% 4.88% 0.50% 1000 100.00% 100.00% 63.23% 9.52% 1.00% 2500 100.00% 100.00% 91.80% 22.12% 2.47% 5000 100.00% 100.00% 99.33% 39.35% 4.88% 10000 100.00% 100.00% 100.00% 63.21% 9.52% ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_BE6D13F6A4554947952B39008B0DC0153E525C2C011DB3MPN1025MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Mike

 <= /p>

A good characterization o= f the inherent difficulty of enabling multicast security. Even assuming tha= t the multicast security was based on public keys in a multiple sender group, which is often the case in IoT, then based on your  Pno= de of .1%, a group with 10 senders with private key has a 1% mesh probabili= ty compromise (it is enough to compromise any one of the senders). Consider= ing that public-key based crypto is much  more side-channel leaky and often hard for developers to get it right comp= ared to directly using the AES co-processor available in most 802.15.4 chip= s, the Pnode probability is going to be much more higher.

 <= /p>

Like every building block= , the risks associated  with compromise of a node need to be taken car= efully into account, especially with multicast that risk goes exponentially as you show. Therefore as you mention a limit to group sizes= and additional mitigations need to be in place. Public key in itself will = not provide that mitigation, it may actually worsen the situation by making= DoS easier by tying up constrained devices in heavy computation. One has to look at the deployment scenario, = perform a risk analysis identifying the threats, and make a solid design to= eliminate those risks. Although you are right and one should not use this = building block in all deployments/use cases, we also firmly believe that the current approach can be an effectiv= e building block for reducing risks in many practical scenarios. Other comp= lementary solutions may need to be created and one solution is not going to= solve all problems.

 <= /p>

Regards=

Sandeep , Sye, Oscar=

 <= /p>

 <= /p>

From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Michael StJohns
Sent: Wednesday, February 12, 2014 5:49 AM
To: dtls-iot@ietf.org
Subject: [Dtls-iot] Compromise numbers for multicast

 

I was trying to figur= e out a way of expressing the issues with shared group symmetric key multic= ast security and the dangers of not properly constraining the size of the m= ulticast group that shares a single key.  I came up with the table below.

The following  table is read with the number of nodes down along the l= eft side, and the probability of any one given node being "compromisab= le" running along the top.  The intersection is the probability o= f the multicast mesh being compromised.

The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a g= iven node being compromisable.

For the IOT constrained node model, I'm generally considering a node compro= misable if it is physically accessible to an attacker.  It *may* also = be compromisable if its accessible via RF (e.g. stack smashing attacks etc)= .  The compromise I care about is an extraction attack on the group key as that gives an attacker the ability t= o masquerade as any node in the mesh, eavesdrop on any traffic, and insert = traffic at will.

So in a mesh of 250 nodes, if there's a .1% chance that any given node is c= ompromisable, the probability of a mesh compromise is 22.13%.  But I w= ould guess that the per node percentage will probably be closer to 1% or gr= eater given the wide set of devices, protections and implementation strategies.

This is no better than a swag, and it's hard to characterize the per node p= robability of compromise given the vast scope of IOT and the huge possible = difference between the least and most capable nodes in a multicast group.&n= bsp; That said, taking 1% probability of mesh compromise as an arbitrary acceptable high water mark and .01% as = an arbitrary Pnode, I wouldn't use shared key multicast security for anythi= ng over a group of 100 nodes and that only for low sensitivity applications= .  If we're talking a Pnode of .1%, that falls to about 10 nodes.  With a Pnode of 1%, that falls to abou= t 2 nodes.

The mitigations for these (physically separate network, hardware security m= odule, physical protections) are mostly not going to be available for const= rained nodes, and the effective Pnode for the whole mesh is the MIN() of al= l of the Pnode's of the mesh (weakest link issue).

Mike



 

5.000000%=

1.000000%=

0.100000%=

0.010000%=

0.001000%=

5

22.62%

4.90%

0.50%

0.05%

0.00%

20

64.15%

18.21%

1.98%

0.20%

0.02%

100<= /o:p>

99.41%

63.40%

9.52%

1.00%

0.10%

250<= /o:p>

100.00%

91.89%

22.13%

2.47%

0.25%

500<= /o:p>

100.00%

99.34%

39.36%

4.88%

0.50%

1000=

100.00%

100.00%

63.23%

9.52%

1.00%

2500=

100.00%

100.00%

91.80%

22.12%

2.47%

5000=

100.00%

100.00%

99.33%

39.35%

4.88%

10000

100.00%

100.00%

100.00%

63.21%

9.52%

 


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_BE6D13F6A4554947952B39008B0DC0153E525C2C011DB3MPN1025MG_-- From mglt.ietf@gmail.com Thu Feb 13 06:45:17 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 845981A01EB; Thu, 13 Feb 2014 06:45:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 zgimlHH1OhYX; Thu, 13 Feb 2014 06:45:14 -0800 (PST) Received: from mail-we0-x233.google.com (mail-we0-x233.google.com [IPv6:2a00:1450:400c:c03::233]) by ietfa.amsl.com (Postfix) with ESMTP id 6A06E1A02C1; Thu, 13 Feb 2014 06:45:14 -0800 (PST) Received: by mail-we0-f179.google.com with SMTP id q58so7477756wes.38 for ; Thu, 13 Feb 2014 06:45:12 -0800 (PST) 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=hPE4ckzUsdckFhohOQs6jUJcFm9Eq3i8eDKXX1OHl9I=; b=bGxGa9GdrTAr5qhZGAJlaoBLtSYE/IbMYuYgchPktCc3UzJ0RWihU25ZR6bzK3B5EX i3omWG8aUwIqLoBLRDt87boKO1rqF+E6jdGKAcgTV1M/4NY9kY3aguWS8n9xics0WAiT 7jngJgGsgj8gY3CUnTl12Ae89LqGcLnJfBYm50Cnn3tExAHHj59WOitGwggdKCPZ5mO0 OG8Io8uHB0Hynjw+cSj6eOizTrXdlt+hMLDGfjUg9sUh3K0Rr0lL6I+oLKC4fk/DhNbi 4KAZZLtFvH8dALR5g7bOoCafa+5JiCBz8/adqS4vRnopC8CLe2v33MplkS64/37oniBz drKw== MIME-Version: 1.0 X-Received: by 10.194.58.180 with SMTP id s20mr1743471wjq.54.1392302712785; Thu, 13 Feb 2014 06:45:12 -0800 (PST) Received: by 10.194.171.129 with HTTP; Thu, 13 Feb 2014 06:45:12 -0800 (PST) In-Reply-To: References: Date: Thu, 13 Feb 2014 15:45:12 +0100 Message-ID: From: Daniel Migault To: Sye Loong Keoh Content-Type: text/plain; charset=ISO-8859-1 Cc: lwip@ietf.org, "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 14:45:17 -0000 Hi, We have not updated the draft to change their names, but I agree they definitely better fit in the LWIG. We would like to present them both in LWIG in London. Note Tero has been provided a 20 minute slot for an overview on "IPsec in constrained environments". So people interested in IoT and security should check the agenda at ipsecme too. [1] http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme On Tue, Feb 4, 2014 at 2:53 AM, Sye Loong Keoh wrote: > Hi Daniel, > > As pointed out by Hannes, DICE WG is not chartered to look at IPSec for IoT. > However, I think your draft might be useful for LWIG WG though. > > Cheers > Sye Loong > > -----Original Message----- > From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Daniel Migault > Sent: Friday, 31 January, 2014 10:48 PM > To: ipsec@ietf.org; dtls-iot@ietf.org > Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP > > Hi, > > Please find the two drafts we have just posted. They are about IPsec/ESP minimal implementation and Diet-ESP designed for IoT. > > Comment are welcome! > > Best Regards, > Daniel > > > Name: draft-mglt-dice-diet-esp > Revision: 00 > Title: Diet-ESP: a flexible and compressed format for IPsec/ESP > Document date: 2014-01-31 > Group: Individual Submission > Pages: 21 > URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt > Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/ > Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00 > > > Abstract: > IPsec/ESP has been designed to secure IP packets exchanged between > two nodes. IPsec implements security at the IP layer which makes > security transparent to the applications, as opposed to TLS or DTLS > that requires application to implement TLS/DTLS. As a result, IPsec > enable to define the security rules in a similar way one establishes > firewall rules. > > One of the IPsec's drawbacks is that implementing security on a per > packet basis adds overhead to each IP packet. Considering IoT > devices, the data transmitted over an IP packet is expected to be > rather small, and the cost of sending extra bytes is so high that > IPsec/ESP can hardly be used for IoT as it is currently defined in > RFC 4303. > > This document defines Diet-ESP, a protocol that compress and reduce > the ESP overhead of IPsec/ESP so that it can fit security and energy > efficient IoT requirements. Diet-ESP use already existing mechanism > like IKEv2 to negotiate the compression format. Furthermore a lot of > information, already existing for an IPsec Security Association, are > reused to offer light negotiation in addition to maximum compression. > > > Name: draft-mglt-lwig-minimal-esp > Revision: 00 > Title: Minimal ESP > Document date: 2014-01-31 > Group: Individual Submission > Pages: 6 > URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt > Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ > Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00 > > > Abstract: > This document describes a minimal version of the IP Encapsulation > Security Payload (ESP) described in RFC 4303 which is part of the > IPsec suite. > > ESP is used to provide confidentiality, data origin authentication, > connectionless integrity, an anti-replay service (a form of partial > sequence integrity), and limited traffic flow confidentiality. > > This document does not update or modify RFC 4303, but provides a > compact description of the minimal version of the protocol. If this > document and RFC 4303 conflicts then RFC 4303 is the authoritative > description. > > > -- > Daniel Migault > Orange Labs -- Security > +33 6 70 72 69 58 > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From rstruik.ext@gmail.com Thu Feb 13 07:02:02 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 D6F101A0209 for ; Thu, 13 Feb 2014 07:02:02 -0800 (PST) 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 I0wQD6sqYR-I for ; Thu, 13 Feb 2014 07:01:57 -0800 (PST) Received: from mail-oa0-x22f.google.com (mail-oa0-x22f.google.com [IPv6:2607:f8b0:4003:c02::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 0A5F31A0293 for ; Thu, 13 Feb 2014 07:01:55 -0800 (PST) Received: by mail-oa0-f47.google.com with SMTP id m1so12699851oag.20 for ; Thu, 13 Feb 2014 07:01:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=w0YhMnlnL7htxHV5SujgF4C7NFSc1ZTCGUF5g5DvH8c=; b=avffwCjbVUxCfpIS1Puh4644zBtR88YsdCXFqmM6tBqST+Ry1q3a4JyzLLUdgXJZiV aMzJimcPq5L11/iXjuWKXcCnOsylY3jDctZncl5K3CVLcWDjmyeH/6QXMpix8HtfOuDW C64mNuxuiVPjeo0HDzX/7dXabah9LvR4eWAd2qKB+ME/FP9UXZIa+FSSCgIxZoKLvA6l laJGjIt6udzlXMzcQzGMcKQGaRkmD8ChWgEnXvHN9v4rVCAg6YqV6rd285gwPlroo2Q7 PHKQa+gwFOKncD3561T4xK6i2QC7QEKvLTQMMI72seqTXWpGipv4yEk/Fwgb6+zviUW/ hFuA== X-Received: by 10.60.142.166 with SMTP id rx6mr1575855oeb.57.1392303714711; Thu, 13 Feb 2014 07:01:54 -0800 (PST) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id o6sm14282408oel.4.2014.02.13.07.01.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 07:01:53 -0800 (PST) Message-ID: <52FCDE53.5050906@gmail.com> Date: Thu, 13 Feb 2014 10:01:39 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , Michael StJohns , "dtls-iot@ietf.org" References: <52FAFD52.2060907@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050307020009040308030104" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:02:03 -0000 This is a multi-part message in MIME format. --------------050307020009040308030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Dear Kumar: I just wanted to respond to part of your email. To-date, state of the art public-key implementations can be done securely and quite efficiently without imposing undue energy cost for computations when compared to communication cost, certainly in hardware. There has been tremendous technical progress the last 15 years, but unfortunately perceptions of that time do not seem to have adapted to newer realities since (at least with IETF email traffic). Please take the quiz in my email to Olaf Bergman on this (http://www.ietf.org/mail-archive/web/ace/current/msg00226.html -- excerpted below). It is under the control of implementers to do a good job; any suggestion that they may not be qualified to do so says more about these implementers than about the technology being implemented. {Happy to help if you need advise} When discussing compromise of keying material, one has to look at impact: with symmetric group keys, compromise of a group key on any device of the key-sharing group compromises any traffic secured by any of them; with public keys, a private signature key is shared with one device only, so its compromise affects that device only and not any other device (assuming no inter dependencies in key hierarchy). Best regards, Rene [excerpt of my email as of February 7, 2014 to the ACE mailing list] I have a quiz question for you all: What is the estimated *total* energy cost of carrying out 30 billion elliptic curve scalar multiplications on RFID-style devices using a best-of-breed hardware only implementation. For simplicity, let us consider 163-bit binary curves. We will ignore any other aspects. Answer options: a) 1 kWh; {10c} b) 1 thousand kWh; c) 1 million kWh; d) 1 billion kWh. There are no prizes. However, I hope this puts the contribution that best-of-breed crypto computations make to global warming (vs. the contribution hereto of email traffic regarding the ACE charter and activities) into perspective. Note: This question was triggered by Cisco's and Intel's forecast that by 2020 there would be 30 billion interconnected objects swarming the planet. Best regards, Rene On 2/13/2014 8:49 AM, Kumar, Sandeep wrote: > > Dear Mike > > A good characterization of the inherent difficulty of enabling > multicast security. Even assuming that the multicast security was > based on public keys in a multiple sender group, which is often the > case in IoT, then based on your Pnode of .1%, a group with 10 senders > with private key has a 1% mesh probability compromise (it is enough to > compromise any one of the senders). Considering that public-key based > crypto is much more side-channel leaky and often hard for developers > to get it right compared to directly using the AES co-processor > available in most 802.15.4 chips, the Pnode probability is going to be > much more higher. > > Like every building block, the risks associated with compromise of a > node need to be taken carefully into account, especially with > multicast that risk goes exponentially as you show. Therefore as you > mention a limit to group sizes and additional mitigations need to be > in place. Public key in itself will not provide that mitigation, it > may actually worsen the situation by making DoS easier by tying up > constrained devices in heavy computation. One has to look at the > deployment scenario, perform a risk analysis identifying the threats, > and make a solid design to eliminate those risks. Although you are > right and one should not use this building block in all > deployments/use cases, we also firmly believe that the current > approach can be an effective building block for reducing risks in many > practical scenarios. Other complementary solutions may need to be > created and one solution is not going to solve all problems. > > Regards > > Sandeep , Sye, Oscar > > *From:*dtls-iot [mailto:dtls-iot-bounces@ietf.org] *On Behalf Of > *Michael StJohns > *Sent:* Wednesday, February 12, 2014 5:49 AM > *To:* dtls-iot@ietf.org > *Subject:* [Dtls-iot] Compromise numbers for multicast > > I was trying to figure out a way of expressing the issues with shared > group symmetric key multicast security and the dangers of not properly > constraining the size of the multicast group that shares a single > key. I came up with the table below. > > The following table is read with the number of nodes down along the > left side, and the probability of any one given node being > "compromisable" running along the top. The intersection is the > probability of the multicast mesh being compromised. > > The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability > of a given node being compromisable. > > For the IOT constrained node model, I'm generally considering a node > compromisable if it is physically accessible to an attacker. It *may* > also be compromisable if its accessible via RF (e.g. stack smashing > attacks etc). The compromise I care about is an extraction attack on > the group key as that gives an attacker the ability to masquerade as > any node in the mesh, eavesdrop on any traffic, and insert traffic at > will. > > So in a mesh of 250 nodes, if there's a .1% chance that any given node > is compromisable, the probability of a mesh compromise is 22.13%. But > I would guess that the per node percentage will probably be closer to > 1% or greater given the wide set of devices, protections and > implementation strategies. > > This is no better than a swag, and it's hard to characterize the per > node probability of compromise given the vast scope of IOT and the > huge possible difference between the least and most capable nodes in a > multicast group. That said, taking 1% probability of mesh compromise > as an arbitrary acceptable high water mark and .01% as an arbitrary > Pnode, I wouldn't use shared key multicast security for anything over > a group of 100 nodes and that only for low sensitivity applications. > If we're talking a Pnode of .1%, that falls to about 10 nodes. With a > Pnode of 1%, that falls to about 2 nodes. > > The mitigations for these (physically separate network, hardware > security module, physical protections) are mostly not going to be > available for constrained nodes, and the effective Pnode for the whole > mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue). > > Mike > > > > > > 5.000000% > > > > 1.000000% > > > > 0.100000% > > > > 0.010000% > > > > 0.001000% > > > > 5 > > > > 22.62% > > > > 4.90% > > > > 0.50% > > > > 0.05% > > > > 0.00% > > > > 20 > > > > 64.15% > > > > 18.21% > > > > 1.98% > > > > 0.20% > > > > 0.02% > > > > 100 > > > > 99.41% > > > > 63.40% > > > > 9.52% > > > > 1.00% > > > > 0.10% > > > > 250 > > > > 100.00% > > > > 91.89% > > > > 22.13% > > > > 2.47% > > > > 0.25% > > > > 500 > > > > 100.00% > > > > 99.34% > > > > 39.36% > > > > 4.88% > > > > 0.50% > > > > 1000 > > > > 100.00% > > > > 100.00% > > > > 63.23% > > > > 9.52% > > > > 1.00% > > > > 2500 > > > > 100.00% > > > > 100.00% > > > > 91.80% > > > > 22.12% > > > > 2.47% > > > > 5000 > > > > 100.00% > > > > 100.00% > > > > 99.33% > > > > 39.35% > > > > 4.88% > > > > 10000 > > > > 100.00% > > > > 100.00% > > > > 100.00% > > > > 63.21% > > > > 9.52% > > > > > > > > > > > > ------------------------------------------------------------------------ > 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. > > > _______________________________________________ > dtls-iot mailing list > dtls-iot@ietf.org > https://www.ietf.org/mailman/listinfo/dtls-iot -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------050307020009040308030104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Dear Kumar:

I just wanted to respond to part of your email.

To-date, state of the art public-key implementations can be done securely and quite efficiently without imposing undue energy cost for computations when compared to communication cost, certainly in hardware. There has been tremendous technical progress the last 15 years, but unfortunately perceptions of that time do not seem to have adapted to newer realities since (at least with IETF email traffic). Please take the quiz in my email to Olaf Bergman on this (http://www.ietf.org/mail-archive/web/ace/current/msg00226.html  -- excerpted below).

It is under the control of implementers to do a good job; any suggestion that they may not be qualified to do so says more about these implementers than about the technology being implemented. {Happy to help if you need advise}

When discussing compromise of keying material, one has to look at impact: with symmetric group keys, compromise of a group key on any device of the key-sharing group compromises any traffic secured by any of them; with public keys, a private signature key is shared with one device only, so its compromise affects that device only and not any other device (assuming no inter dependencies in key hierarchy).

Best regards, Rene 

[excerpt of my email as of February 7, 2014 to the ACE mailing list]

I have a quiz question for you all:

What is the estimated *total* energy cost of carrying out 30 billion elliptic curve scalar multiplications on RFID-style devices using a best-of-breed hardware only implementation. For simplicity, let us consider 163-bit binary curves. We will ignore any other aspects.

Answer options:
a) 1 kWh; {10c}
b) 1 thousand kWh;
c) 1 million kWh;
d) 1 billion kWh.

There are no prizes. However, I hope this puts the contribution that best-of-breed crypto computations make to global warming (vs. the contribution hereto of email traffic regarding the ACE charter and activities) into perspective.

Note: This question was triggered by Cisco's and Intel's forecast that by 2020 there would be 30 billion interconnected objects swarming the planet.

Best regards, Rene


On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:

Dear Mike

 

A good characterization of the inherent difficulty of enabling multicast security. Even assuming that the multicast security was based on public keys in a multiple sender group, which is often the case in IoT, then based on your  Pnode of .1%, a group with 10 senders with private key has a 1% mesh probability compromise (it is enough to compromise any one of the senders). Considering that public-key based crypto is much  more side-channel leaky and often hard for developers to get it right compared to directly using the AES co-processor available in most 802.15.4 chips, the Pnode probability is going to be much more higher.

 

Like every building block, the risks associated  with compromise of a node need to be taken carefully into account, especially with multicast that risk goes exponentially as you show. Therefore as you mention a limit to group sizes and additional mitigations need to be in place. Public key in itself will not provide that mitigation, it may actually worsen the situation by making DoS easier by tying up constrained devices in heavy computation. One has to look at the deployment scenario, perform a risk analysis identifying the threats, and make a solid design to eliminate those risks. Although you are right and one should not use this building block in all deployments/use cases, we also firmly believe that the current approach can be an effective building block for reducing risks in many practical scenarios. Other complementary solutions may need to be created and one solution is not going to solve all problems.

 

Regards

Sandeep , Sye, Oscar

 

 

From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Michael StJohns
Sent: Wednesday, February 12, 2014 5:49 AM
To: dtls-iot@ietf.org
Subject: [Dtls-iot] Compromise numbers for multicast

 

I was trying to figure out a way of expressing the issues with shared group symmetric key multicast security and the dangers of not properly constraining the size of the multicast group that shares a single key.  I came up with the table below.

The following  table is read with the number of nodes down along the left side, and the probability of any one given node being "compromisable" running along the top.  The intersection is the probability of the multicast mesh being compromised.

The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a given node being compromisable.

For the IOT constrained node model, I'm generally considering a node compromisable if it is physically accessible to an attacker.  It *may* also be compromisable if its accessible via RF (e.g. stack smashing attacks etc).  The compromise I care about is an extraction attack on the group key as that gives an attacker the ability to masquerade as any node in the mesh, eavesdrop on any traffic, and insert traffic at will.

So in a mesh of 250 nodes, if there's a .1% chance that any given node is compromisable, the probability of a mesh compromise is 22.13%.  But I would guess that the per node percentage will probably be closer to 1% or greater given the wide set of devices, protections and implementation strategies.

This is no better than a swag, and it's hard to characterize the per node probability of compromise given the vast scope of IOT and the huge possible difference between the least and most capable nodes in a multicast group.  That said, taking 1% probability of mesh compromise as an arbitrary acceptable high water mark and .01% as an arbitrary Pnode, I wouldn't use shared key multicast security for anything over a group of 100 nodes and that only for low sensitivity applications.  If we're talking a Pnode of .1%, that falls to about 10 nodes.  With a Pnode of 1%, that falls to about 2 nodes.

The mitigations for these (physically separate network, hardware security module, physical protections) are mostly not going to be available for constrained nodes, and the effective Pnode for the whole mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue).

Mike



 

5.000000%

1.000000%

0.100000%

0.010000%

0.001000%

5

22.62%

4.90%

0.50%

0.05%

0.00%

20

64.15%

18.21%

1.98%

0.20%

0.02%

100

99.41%

63.40%

9.52%

1.00%

0.10%

250

100.00%

91.89%

22.13%

2.47%

0.25%

500

100.00%

99.34%

39.36%

4.88%

0.50%

1000

100.00%

100.00%

63.23%

9.52%

1.00%

2500

100.00%

100.00%

91.80%

22.12%

2.47%

5000

100.00%

100.00%

99.33%

39.35%

4.88%

10000

100.00%

100.00%

100.00%

63.21%

9.52%







 


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.
 

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



-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------050307020009040308030104-- From sandeep.kumar@philips.com Thu Feb 13 07:18: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 D51C61A02A3 for ; Thu, 13 Feb 2014 07:18:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FdPUcBkmLWUQ for ; Thu, 13 Feb 2014 07:18:25 -0800 (PST) Received: from ch1outboundpool.messaging.microsoft.com (ch1ehsobe004.messaging.microsoft.com [216.32.181.184]) by ietfa.amsl.com (Postfix) with ESMTP id C3E3C1A0209 for ; Thu, 13 Feb 2014 07:18:24 -0800 (PST) Received: from mail60-ch1-R.bigfish.com (10.43.68.234) by CH1EHSOBE003.bigfish.com (10.43.70.53) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 15:18:23 +0000 Received: from mail60-ch1 (localhost [127.0.0.1]) by mail60-ch1-R.bigfish.com (Postfix) with ESMTP id 0F3D440627; Thu, 13 Feb 2014 15:18:23 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zzbb2dI98dI15d6O9371I1431Jc85fhe0eah9251I7f52h217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received: from mail60-ch1 (localhost.localdomain [127.0.0.1]) by mail60-ch1 (MessageSwitch) id 1392304700261687_24947; Thu, 13 Feb 2014 15:18:20 +0000 (UTC) Received: from CH1EHSMHS011.bigfish.com (snatpool2.int.messaging.microsoft.com [10.43.68.236]) by mail60-ch1.bigfish.com (Postfix) with ESMTP id 39EE62400D8; Thu, 13 Feb 2014 15:18:20 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CH1EHSMHS011.bigfish.com (10.43.70.11) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 15:18:20 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.200]) by 011-DB3MMR1-011.MGDPHG.emi.philips.com ([10.128.28.50]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 15:18:05 +0000 From: "Kumar, Sandeep" To: Rene Struik , Michael StJohns , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Compromise numbers for multicast Thread-Index: AQHPJ63G//94FoEpxUCFJ03s4UqMxZqzNGxggAAVNoCAAAHhYA== Date: Thu, 13 Feb 2014 15:18:04 +0000 Message-ID: References: <52FAFD52.2060907@nthpermutation.com> <52FCDE53.5050906@gmail.com> In-Reply-To: <52FCDE53.5050906@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.109] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E5260E7011DB3MPN1025MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 15:18:32 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E5260E7011DB3MPN1025MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Rene Sure you can help creating the right implementation but in a multi-vendor s= etting where one device can compromise the group, you need to advice all th= e vendors - will make you a billionaire ;) I do not agree with your statement "with public keys, a private signature k= ey is shared with one device only, so its compromise affects that device on= ly and not any other device'. In a multicast scenario compromising one priv= ate key of any sender would be enough to send control commands to all devi= ces in the group, so it does affect all devices until that key is revoked. Regards Sandeep From: Rene Struik [mailto:rstruik.ext@gmail.com] Sent: Thursday, February 13, 2014 4:02 PM To: Kumar, Sandeep; Michael StJohns; dtls-iot@ietf.org Subject: Re: [Dtls-iot] Compromise numbers for multicast Dear Kumar: I just wanted to respond to part of your email. To-date, state of the art public-key implementations can be done securely a= nd quite efficiently without imposing undue energy cost for computations wh= en compared to communication cost, certainly in hardware. There has been tr= emendous technical progress the last 15 years, but unfortunately perception= s of that time do not seem to have adapted to newer realities since (at lea= st with IETF email traffic). Please take the quiz in my email to Olaf Bergm= an on this (http://www.ietf.org/mail-archive/web/ace/current/msg00226.html = -- excerpted below). It is under the control of implementers to do a good job; any suggestion th= at they may not be qualified to do so says more about these implementers th= an about the technology being implemented. {Happy to help if you need advis= e} When discussing compromise of keying material, one has to look at impact: w= ith symmetric group keys, compromise of a group key on any device of the ke= y-sharing group compromises any traffic secured by any of them; with public= keys, a private signature key is shared with one device only, so its compr= omise affects that device only and not any other device (assuming no inter = dependencies in key hierarchy). Best regards, Rene [excerpt of my email as of February 7, 2014 to the ACE mailing list] I have a quiz question for you all: What is the estimated *total* energy cost of carrying out 30 billion ellipt= ic curve scalar multiplications on RFID-style devices using a best-of-breed= hardware only implementation. For simplicity, let us consider 163-bit bina= ry curves. We will ignore any other aspects. Answer options: a) 1 kWh; {10c} b) 1 thousand kWh; c) 1 million kWh; d) 1 billion kWh. There are no prizes. However, I hope this puts the contribution that best-o= f-breed crypto computations make to global warming (vs. the contribution he= reto of email traffic regarding the ACE charter and activities) into perspe= ctive. Note: This question was triggered by Cisco's and Intel's forecast that by 2= 020 there would be 30 billion interconnected objects swarming the planet. Best regards, Rene On 2/13/2014 8:49 AM, Kumar, Sandeep wrote: Dear Mike A good characterization of the inherent difficulty of enabling multicast se= curity. Even assuming that the multicast security was based on public keys = in a multiple sender group, which is often the case in IoT, then based on y= our Pnode of .1%, a group with 10 senders with private key has a 1% mesh p= robability compromise (it is enough to compromise any one of the senders). = Considering that public-key based crypto is much more side-channel leaky a= nd often hard for developers to get it right compared to directly using the= AES co-processor available in most 802.15.4 chips, the Pnode probability i= s going to be much more higher. Like every building block, the risks associated with compromise of a node = need to be taken carefully into account, especially with multicast that ris= k goes exponentially as you show. Therefore as you mention a limit to group= sizes and additional mitigations need to be in place. Public key in itself= will not provide that mitigation, it may actually worsen the situation by = making DoS easier by tying up constrained devices in heavy computation. One= has to look at the deployment scenario, perform a risk analysis identifyin= g the threats, and make a solid design to eliminate those risks. Although y= ou are right and one should not use this building block in all deployments/= use cases, we also firmly believe that the current approach can be an effec= tive building block for reducing risks in many practical scenarios. Other c= omplementary solutions may need to be created and one solution is not going= to solve all problems. Regards Sandeep , Sye, Oscar From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Michael StJo= hns Sent: Wednesday, February 12, 2014 5:49 AM To: dtls-iot@ietf.org Subject: [Dtls-iot] Compromise numbers for multicast I was trying to figure out a way of expressing the issues with shared group= symmetric key multicast security and the dangers of not properly constrain= ing the size of the multicast group that shares a single key. I came up wi= th the table below. The following table is read with the number of nodes down along the left s= ide, and the probability of any one given node being "compromisable" runnin= g along the top. The intersection is the probability of the multicast mesh= being compromised. The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a g= iven node being compromisable. For the IOT constrained node model, I'm generally considering a node compro= misable if it is physically accessible to an attacker. It *may* also be co= mpromisable if its accessible via RF (e.g. stack smashing attacks etc). Th= e compromise I care about is an extraction attack on the group key as that = gives an attacker the ability to masquerade as any node in the mesh, eavesd= rop on any traffic, and insert traffic at will. So in a mesh of 250 nodes, if there's a .1% chance that any given node is c= ompromisable, the probability of a mesh compromise is 22.13%. But I would = guess that the per node percentage will probably be closer to 1% or greater= given the wide set of devices, protections and implementation strategies. This is no better than a swag, and it's hard to characterize the per node p= robability of compromise given the vast scope of IOT and the huge possible = difference between the least and most capable nodes in a multicast group. = That said, taking 1% probability of mesh compromise as an arbitrary accepta= ble high water mark and .01% as an arbitrary Pnode, I wouldn't use shared k= ey multicast security for anything over a group of 100 nodes and that only = for low sensitivity applications. If we're talking a Pnode of .1%, that fa= lls to about 10 nodes. With a Pnode of 1%, that falls to about 2 nodes. The mitigations for these (physically separate network, hardware security m= odule, physical protections) are mostly not going to be available for const= rained nodes, and the effective Pnode for the whole mesh is the MIN() of al= l of the Pnode's of the mesh (weakest link issue). Mike 5.000000% 1.000000% 0.100000% 0.010000% 0.001000% 5 22.62% 4.90% 0.50% 0.05% 0.00% 20 64.15% 18.21% 1.98% 0.20% 0.02% 100 99.41% 63.40% 9.52% 1.00% 0.10% 250 100.00% 91.89% 22.13% 2.47% 0.25% 500 100.00% 99.34% 39.36% 4.88% 0.50% 1000 100.00% 100.00% 63.23% 9.52% 1.00% 2500 100.00% 100.00% 91.80% 22.12% 2.47% 5000 100.00% 100.00% 99.33% 39.35% 4.88% 10000 100.00% 100.00% 100.00% 63.21% 9.52% ________________________________ 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. _______________________________________________ dtls-iot mailing list dtls-iot@ietf.org https://www.ietf.org/mailman/listinfo/dtls-iot -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --_000_BE6D13F6A4554947952B39008B0DC0153E5260E7011DB3MPN1025MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Rene

 

Sure you can help crea= ting the right implementation but in a multi-vendor setting where one devic= e can compromise the group, you need to advice all the vendors – will make you a billionaire ;)

 

I do not agree with yo= ur statement “with public key= s, a private signature key is shared with one device only, so its compromise affects that device only and not any other device’. In a = multicast scenario compromising one private key of  any sender would b= e enough to send control commands to all devices in the group, so it does a= ffect all devices until that key is revoked.

 

Regards<= /span>

Sandeep

 <= /p>

From: Rene Struik [mailto:rstruik.ext@gmail.com]
Sent: Thursday, February 13, 2014 4:02 PM
To: Kumar, Sandeep; Michael StJohns; dtls-iot@ietf.org
Subject: Re: [Dtls-iot] Compromise numbers for multicast<= /span>

 

Dear Kumar:

I just wanted to respond to part of your email.

To-date, state of the art public-key implementations can be done securely a= nd quite efficiently without imposing undue energy cost for computations wh= en compared to communication cost, certainly in hardware. There has been tr= emendous technical progress the last 15 years, but unfortunately perceptions of that time do not seem to h= ave adapted to newer realities since (at least with IETF email traffic). Pl= ease take the quiz in my email to Olaf Bergman on this (http://www.ietf.org= /mail-archive/web/ace/current/msg00226.html  -- excerpted below).

It is under the control of implementers to do a good job; any suggestion th= at they may not be qualified to do so says more about these implementers th= an about the technology being implemented. {Happy to help if you need advis= e}

When discussing compromise of keying material, one has to look at impact: w= ith symmetric group keys, compromise of a group key on any device of the ke= y-sharing group compromises any traffic secured by any of them; with public= keys, a private signature key is shared with one device only, so its compromise affects that device only an= d not any other device (assuming no inter dependencies in key hierarchy).
Best regards, Rene 

 
 
[excerpt of my email as of February 7, 2014 to the ACE mailing list]
 
I have a quiz question for you all:
 
What is the estimated *total* energy cost of carrying out 30 billion e=
lliptic curve scalar multiplications on RFID-style devices using a best-of-=
breed hardware only implementation. For simplicity, let us consider 163-bit=
 binary curves. We will ignore any other aspects.
 
Answer options:
a) 1 kWh; {10c}
b) 1 thousand kWh;
c) 1 million kWh;
d) 1 billion kWh.
 
There are no prizes. However, I hope this puts the contribution that b=
est-of-breed crypto computations make to global warming (vs. the contributi=
on hereto of email traffic regarding the ACE charter and activities) into p=
erspective.
 
Note: This question was triggered by Cisco's and Intel's forecast that=
 by 2020 there would be 30 billion interconnected objects swarming the plan=
et.
 
Best regards, Rene



On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:

Dear Mike

 <= /p>

A good characterization o= f the inherent difficulty of enabling multicast security. Even assuming tha= t the multicast security was based on public keys in a multiple sender group, which is often the case in IoT, then based on your  Pno= de of .1%, a group with 10 senders with private key has a 1% mesh probabili= ty compromise (it is enough to compromise any one of the senders). Consider= ing that public-key based crypto is much  more side-channel leaky and often hard for developers to get it right comp= ared to directly using the AES co-processor available in most 802.15.4 chip= s, the Pnode probability is going to be much more higher.

 <= /p>

Like every building block= , the risks associated  with compromise of a node need to be taken car= efully into account, especially with multicast that risk goes exponentially as you show. Therefore as you mention a limit to group sizes= and additional mitigations need to be in place. Public key in itself will = not provide that mitigation, it may actually worsen the situation by making= DoS easier by tying up constrained devices in heavy computation. One has to look at the deployment scenario, = perform a risk analysis identifying the threats, and make a solid design to= eliminate those risks. Although you are right and one should not use this = building block in all deployments/use cases, we also firmly believe that the current approach can be an effectiv= e building block for reducing risks in many practical scenarios. Other comp= lementary solutions may need to be created and one solution is not going to= solve all problems.

 <= /p>

Regards=

Sandeep , Sye, Oscar

 <= /p>

 <= /p>

From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Michael StJohns
Sent: Wednesday, February 12, 2014 5:49 AM
To: dtls-iot@ietf.org
Subject: [Dtls-iot] Compromise numbers for multicast

 

I was trying to figur= e out a way of expressing the issues with shared group symmetric key multic= ast security and the dangers of not properly constraining the size of the m= ulticast group that shares a single key.  I came up with the table below.

The following  table is read with the number of nodes down along the l= eft side, and the probability of any one given node being "compromisab= le" running along the top.  The intersection is the probability o= f the multicast mesh being compromised.

The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a g= iven node being compromisable.

For the IOT constrained node model, I'm generally considering a node compro= misable if it is physically accessible to an attacker.  It *may* also = be compromisable if its accessible via RF (e.g. stack smashing attacks etc)= .  The compromise I care about is an extraction attack on the group key as that gives an attacker the ability t= o masquerade as any node in the mesh, eavesdrop on any traffic, and insert = traffic at will.

So in a mesh of 250 nodes, if there's a .1% chance that any given node is c= ompromisable, the probability of a mesh compromise is 22.13%.  But I w= ould guess that the per node percentage will probably be closer to 1% or gr= eater given the wide set of devices, protections and implementation strategies.

This is no better than a swag, and it's hard to characterize the per node p= robability of compromise given the vast scope of IOT and the huge possible = difference between the least and most capable nodes in a multicast group.&n= bsp; That said, taking 1% probability of mesh compromise as an arbitrary acceptable high water mark and .01% as = an arbitrary Pnode, I wouldn't use shared key multicast security for anythi= ng over a group of 100 nodes and that only for low sensitivity applications= .  If we're talking a Pnode of .1%, that falls to about 10 nodes.  With a Pnode of 1%, that falls to abou= t 2 nodes.

The mitigations for these (physically separate network, hardware security m= odule, physical protections) are mostly not going to be available for const= rained nodes, and the effective Pnode for the whole mesh is the MIN() of al= l of the Pnode's of the mesh (weakest link issue).

Mike




 

5.000000%=

1.000000%=

0.100000%=

0.010000%=

0.001000%=

5

22.62%

4.90%

0.50%

0.05%

0.00%

20

64.15%

18.21%

1.98%

0.20%

0.02%

100<= /o:p>

99.41%

63.40%

9.52%

1.00%

0.10%

250<= /o:p>

100.00%

91.89%

22.13%

2.47%

0.25%

500<= /o:p>

100.00%

99.34%

39.36%

4.88%

0.50%

1000=

100.00%

100.00%

63.23%

9.52%

1.00%

2500=

100.00%

100.00%

91.80%

22.12%

2.47%

5000=

100.00%

100.00%

99.33%

39.35%

4.88%

10000

100.00%

100.00%

100.00%

63.21%

9.52%

 

 

The information contained in th= is 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 proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.



_______________________________________________
dtls-iot mailing list
dtls-iot@ietf.org<=
/pre>

https://www=
.ietf.org/mailman/listinfo/dtls-iot






-- 
email: rstruik.ext@gmail.com<=
/a> | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--_000_BE6D13F6A4554947952B39008B0DC0153E5260E7011DB3MPN1025MG_-- From msj@nthpermutation.com Thu Feb 13 08:38:22 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 C60301A0361 for ; Thu, 13 Feb 2014 08:38:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ORWvdSkhM7OB for ; Thu, 13 Feb 2014 08:38:20 -0800 (PST) Received: from mail-qa0-f53.google.com (mail-qa0-f53.google.com [209.85.216.53]) by ietfa.amsl.com (Postfix) with ESMTP id CE9501A035E for ; Thu, 13 Feb 2014 08:37:59 -0800 (PST) Received: by mail-qa0-f53.google.com with SMTP id cm18so16557149qab.12 for ; Thu, 13 Feb 2014 08:37:58 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=frWLYtcKvCRy+NhsMOxM7jqD5/3udy+Tzn7Ihq9OH2E=; b=edawY7XPMmf4I+QJu+pO8NrZQBxrwb3TUDUk86hjy8/kOcAp046OkyvKFErCOlUXdh tPoNJWryS+Ve4fhr5QN3XL8PdmVx3flKoUmyMfDIeXoX8Ot5UWS7QKI3NFjBeJ9SfS0M g4PpFgadQrukcDl1SaiSW+DKW5y7SOGtD6fpkvdrcagM9BU6uFsr2P+zIR3XQxXnOy0L 4OYEbd2yamhhUvf0RN7tv6f+tXam+3PaMfPRlKrelHfrEZTOGnmyI3kUpaqnKSVEMZhn stDqz5XFeq9ux2ZkPjb687rljBNkOFhkMrTTMb0vB48QO8Z4xxq2zPiqiuuO7plrQ58z QeDA== X-Gm-Message-State: ALoCoQk43FXVfh7OlJcaFEqk5dSqjBQCp6JEFOWn4Zvi01nBZFpxwjZNY9bP2iZXyt6RroWuNmz+ X-Received: by 10.229.179.69 with SMTP id bp5mr4170828qcb.17.1392309478139; Thu, 13 Feb 2014 08:37:58 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id y71sm3309252qgd.3.2014.02.13.08.37.57 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 08:37:57 -0800 (PST) Message-ID: <52FCF4F8.1050106@nthpermutation.com> Date: Thu, 13 Feb 2014 11:38:16 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , Rene Struik , "dtls-iot@ietf.org" References: <52FAFD52.2060907@nthpermutation.com> <52FCDE53.5050906@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------030109050507070004030104" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:38:23 -0000 This is a multi-part message in MIME format. --------------030109050507070004030104 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/13/2014 10:18 AM, Kumar, Sandeep wrote: > I do not agree with your statement "with public keys, a private > signature key is shared with one device only, so its compromise > affects that device only and not any other device'. In a multicast > scenario compromising one private key of any sender would be enough > to send control commands to all devices in the group, so it does > affect all devices until that key is revoked. Let's try stating this a slightly different way - A private key is shared with one device only, but that device is one of many and requires an attacker to identify it and target it specifically. So the Pnode for that device is Pdisc * MAX (Pphys, Plog), where Pdisc is the probability an attacker can identify it, Pphys is the probability the node is physically compromisable, and Plog is the probability that the node is compromisable OTA. The probability of mesh compromise is 1-((1-Pnode)^numControllers) - or Pnode if there is only one controller. You're correct that if you compromise the device, you can send control commands, but given that your example is lighting control, that the typical control for lighting is a light switch, and that if you're physically next to the light switch you can flip it on or off without any need to compromise the device.... well. The key point about sequestering control credentials to only those devices authorized to issue commands is that it's relatively easy to identify which devices a) need more physical protection, b) need more logical protection, c) have enough value that spending money to protect the credentials does not break the bank (e.g. 1 expensive light switch, 100 inexpensive light bulbs). Mike --------------030109050507070004030104 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2/13/2014 10:18 AM, Kumar, Sandeep wrote:
I do not agree with your statement “with public keys, a private signature key is shared with one device only, so its compromise affects that device only and not any other device’. In a multicast scenario compromising one private key of  any sender would be enough to send control commands to all devices in the group, so it does affect all devices until that key is revoked.

Let's try stating this a slightly different way -

A private key is shared with one device only, but that device is one of many and requires an attacker to identify it and target it specifically.  So the Pnode for that device is Pdisc * MAX (Pphys, Plog), where Pdisc is the probability an attacker can identify it, Pphys is the probability the node is physically compromisable, and Plog is the probability that the node is compromisable OTA.  The probability of mesh compromise is 1-((1-Pnode)^numControllers) - or Pnode if there is only one controller.

You're correct that if you compromise the device, you can send control commands, but given that your example is lighting control, that the typical control for lighting is a light switch, and that if you're physically next to the light switch you can flip it on or off without any need to compromise the device.... well.    

The key point about sequestering control credentials to only those devices authorized to issue commands is that it's relatively easy to identify which devices a) need more physical protection, b) need more logical protection, c) have enough value that spending money to protect the credentials does not break the bank (e.g. 1 expensive light switch, 100 inexpensive light bulbs).

Mike

--------------030109050507070004030104-- From msj@nthpermutation.com Thu Feb 13 08:40: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 503F51A0333 for ; Thu, 13 Feb 2014 08:40:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tom7Y8oKzTsv for ; Thu, 13 Feb 2014 08:40:27 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 8E4BD1A033F for ; Thu, 13 Feb 2014 08:40:27 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i8so18149321qcq.18 for ; Thu, 13 Feb 2014 08:40:26 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=Z8XS0VH2YgwqrlURPlJaoVJ5WSuOIZP8KL/5G6/Wyd8=; b=J1hOQl6/EdiQdhvDsD+PgBhx5P+LdOX/DWTwSwDorOq42LA9YA4YfnQpeBr4vQFrA3 DLbMv2nU5Q5/8pCK0KJsG03h1ipg1jp69ch/InBTH0qzYAiJbI7vTOlPV+bKDN5pL7lD 3yOjqjLVnqAu5hdMfmMxTHCAJ9zSL/3XoxRkBPdaWVWd9vp7g9rCbPD0/GPir1MXqqoD NrFYxVEdK2XOPiHmd97mEI66tnAztdfcEOZtiaET1ypkHqEgYC4rIufRYiWt0AESEv5I clqXa8QdIM8jHq+ZEFm3aBQQsEscMomn2XYzT/DhqAlYj/pkkQGfwHXWV8FsMl/d3IUr 4G6g== X-Gm-Message-State: ALoCoQkNJCOhLyMLRLsMgpbzBB1SNVOQjdnwVFOfD6/sgIR08mPczEwIB8bWBvJuHul7cuxslDfV X-Received: by 10.224.136.67 with SMTP id q3mr4257099qat.32.1392309625829; Thu, 13 Feb 2014 08:40:25 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id f10sm6777954qar.12.2014.02.13.08.40.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 08:40:25 -0800 (PST) Message-ID: <52FCF58A.9090909@nthpermutation.com> Date: Thu, 13 Feb 2014 11:40:42 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , "dtls-iot@ietf.org" References: <52FAFD52.2060907@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------060809020608030009030709" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:40:29 -0000 This is a multi-part message in MIME format. --------------060809020608030009030709 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/13/2014 8:49 AM, Kumar, Sandeep wrote: > Other complementary solutions may need to be created and one solution > is not going to solve all problems. Which is probably the strongest argument for moving security protections to the "problem" or application level! Mike --------------060809020608030009030709 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:
Other complementary solutions may need to be created and one solution is not going to solve all problems.

Which is probably the strongest argument for moving security protections to the "problem" or application level!

Mike

--------------060809020608030009030709-- From sandeep.kumar@philips.com Thu Feb 13 08:46:56 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 CED191A035E for ; Thu, 13 Feb 2014 08:46:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 Q6xFz4HGuyRT for ; Thu, 13 Feb 2014 08:46:54 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe005.messaging.microsoft.com [65.55.88.15]) by ietfa.amsl.com (Postfix) with ESMTP id 814971A0281 for ; Thu, 13 Feb 2014 08:46:53 -0800 (PST) Received: from mail204-tx2-R.bigfish.com (10.9.14.228) by TX2EHSOBE002.bigfish.com (10.9.40.22) with Microsoft SMTP Server id 14.1.225.22; Thu, 13 Feb 2014 16:46:52 +0000 Received: from mail204-tx2 (localhost [127.0.0.1]) by mail204-tx2-R.bigfish.com (Postfix) with ESMTP id 12F5EDC00DA; Thu, 13 Feb 2014 16:46:52 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -29 X-BigFish: VPS-29(zzbb2dI98dI15d6O9371Ic85fhe0eah9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh8275dh18c673h1de097h186068hz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received: from mail204-tx2 (localhost.localdomain [127.0.0.1]) by mail204-tx2 (MessageSwitch) id 1392310010615422_17514; Thu, 13 Feb 2014 16:46:50 +0000 (UTC) Received: from TX2EHSMHS035.bigfish.com (unknown [10.9.14.253]) by mail204-tx2.bigfish.com (Postfix) with ESMTP id 885E320006D; Thu, 13 Feb 2014 16:46:50 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS035.bigfish.com (10.9.99.135) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 13 Feb 2014 16:46:49 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.200]) by 011-DB3MMR1-005.MGDPHG.emi.philips.com ([10.128.28.55]) with mapi id 14.03.0174.002; Thu, 13 Feb 2014 16:46:48 +0000 From: "Kumar, Sandeep" To: Michael StJohns , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] Compromise numbers for multicast Thread-Index: AQHPJ63G//94FoEpxUCFJ03s4UqMxZqzNGxggAAw4wCAAADhYA== Date: Thu, 13 Feb 2014 16:46:47 +0000 Message-ID: References: <52FAFD52.2060907@nthpermutation.com> <52FCF58A.9090909@nthpermutation.com> In-Reply-To: <52FCF58A.9090909@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E52669F011DB3MPN1025MG_" MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:46:57 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E52669F011DB3MPN1025MG_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable It not just moving, but creating the complementary solution for source auth= enticity at the application level, the transport level provides the one lev= el of defense in the layered approach. Sandeep From: Michael StJohns [mailto:msj@nthpermutation.com] Sent: Thursday, February 13, 2014 5:41 PM To: Kumar, Sandeep; dtls-iot@ietf.org Subject: Re: [Dtls-iot] Compromise numbers for multicast On 2/13/2014 8:49 AM, Kumar, Sandeep wrote: Other complementary solutions may need to be created and one solution is no= t going to solve all problems. Which is probably the strongest argument for moving security protections to= the "problem" or application level! Mike ________________________________ The information contained in this message may be confidential and legally p= rotected under applicable law. The message is intended solely for the addre= ssee(s). If you are not the intended recipient, you are hereby notified tha= t any use, forwarding, dissemination, or reproduction of this message is st= rictly prohibited and may be unlawful. If you are not the intended recipien= t, please contact the sender by return e-mail and destroy all copies of the= original message. --_000_BE6D13F6A4554947952B39008B0DC0153E52669F011DB3MPN1025MG_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

It not just moving, but c= reating the complementary solution for source authenticity at the applicati= on level, the transport level provides the one level of defense in the layered approach.

 <= /p>

Sandeep

 <= /p>

From: Michael StJohns [mailto:msj@nthpermutation.com]
Sent: Thursday, February 13, 2014 5:41 PM
To: Kumar, Sandeep; dtls-iot@ietf.org
Subject: Re: [Dtls-iot] Compromise numbers for multicast<= /span>

 

On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:

Other complementary solut= ions may need to be created and one solution is not going to solve all prob= lems.


Which is probably the strongest argument for moving security protections to= the "problem" or application level!

Mike


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_BE6D13F6A4554947952B39008B0DC0153E52669F011DB3MPN1025MG_-- From msj@nthpermutation.com Thu Feb 13 08:51:09 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 72AEA1A0305 for ; Thu, 13 Feb 2014 08:51:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fWCRpxgIkpkM for ; Thu, 13 Feb 2014 08:51:07 -0800 (PST) Received: from mail-qa0-f41.google.com (mail-qa0-f41.google.com [209.85.216.41]) by ietfa.amsl.com (Postfix) with ESMTP id 5D09E1A02C3 for ; Thu, 13 Feb 2014 08:51:07 -0800 (PST) Received: by mail-qa0-f41.google.com with SMTP id w8so16605768qac.28 for ; Thu, 13 Feb 2014 08:51:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type; bh=HuAojrT1i2dW5Z+Nv/cEcHwgh0b53+G5qblFPqTYTFM=; b=jUzxxFn6oPAt0ExHtd/1jFjXxU8ev+kryCNTao7UmLarTnM7xJt8QjnMtdwa4RvO+u cYpv5vPIskqA7jTKDOunoomIrxKkOytg9v5CJWrkV+g2PvHEoxDZm5YpjJLr460g/JiQ PgvVa62yYc5hGzLx+weYttm8+eYjE6pyG9v4NHzNYTuamcg83D2qVEvi/wdTPPG291pS Aa45FggbwDkT7y7A41iM33rzKLIhdnMu8uqaTaBG6MV5N5eizj5sCOrcRelet3nRx0Hm TgjwAC/ZEhIdtI4L1G07Nr8/2PWG2FMFX3sTZuYtG78YpWBUx/qdcB5fUC/HOPEZcEDf j8cA== X-Gm-Message-State: ALoCoQlVio1JJ7/47tiK0066fTrzoK/NZApg1N/zk1VmEmiwuRYR5OoTpIAcGNA/2lh/tadamYj0 X-Received: by 10.224.3.10 with SMTP id 10mr4323563qal.58.1392310265950; Thu, 13 Feb 2014 08:51:05 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id q10sm6854402qaj.13.2014.02.13.08.51.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 08:51:05 -0800 (PST) Message-ID: <52FCF80B.5060807@nthpermutation.com> Date: Thu, 13 Feb 2014 11:51:23 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , "dtls-iot@ietf.org" References: <52FAFD52.2060907@nthpermutation.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------020300010208030004090300" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 16:51:09 -0000 This is a multi-part message in MIME format. --------------020300010208030004090300 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit On 2/13/2014 8:49 AM, Kumar, Sandeep wrote: > A good characterization of the inherent difficulty of enabling > multicast security. Even assuming that the multicast security was > based on public keys in a multiple sender group, which is often the > case in IoT, then based on your Pnode of .1%, a group with 10 senders > with private key has a 1% mesh probability compromise (it is enough to > compromise any one of the senders). Considering that public-key based > crypto is much more side-channel leaky and often hard for developers > to get it right compared to directly using the AES co-processor > available in most 802.15.4 chips, the Pnode probability is going to be > much more higher. If you have unfettered physical access to a device and time to work, Pnode is 100% barring hardware protection of the key material and operating environment (e.g. wiping the keys if the device is physically penetrated, verifying the OS and firmware, etc). If you only have OTA access, or are sniffing the protocols, side channel attacks tend to be a bit more difficult to execute. With respect to hardware chips - if they'd spec'd decent public key security in the various protocols that the chips were built for in the first place, we wouldn't be arguing this much. So let's not build our protocols based on the limitations of the hardware of the previous years and weak protocols. --------------020300010208030004090300 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:
A good characterization of the inherent difficulty of enabling multicast security. Even assuming that the multicast security was based on public keys in a multiple sender group, which is often the case in IoT, then based on your  Pnode of .1%, a group with 10 senders with private key has a 1% mesh probability compromise (it is enough to compromise any one of the senders). Considering that public-key based crypto is much  more side-channel leaky and often hard for developers to get it right compared to directly using the AES co-processor available in most 802.15.4 chips, the Pnode probability is going to be much more higher.

If you have unfettered physical access to a device and time to work, Pnode is 100% barring hardware protection of the key material and operating environment (e.g. wiping the keys if the device is physically penetrated, verifying the OS and firmware, etc).    If you only have OTA access, or are sniffing the protocols, side channel attacks tend to be a bit more difficult to execute.

With respect to hardware chips - if they'd spec'd decent public key security in the various protocols that the chips were built for in the first place, we wouldn't be arguing this much.  So let's not build our protocols based on the limitations of the hardware of the previous years and weak protocols. 


--------------020300010208030004090300-- From rstruik.ext@gmail.com Thu Feb 13 09:17:37 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 925B21A02DA for ; Thu, 13 Feb 2014 09:17:37 -0800 (PST) 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 p47r37BR8ioH for ; Thu, 13 Feb 2014 09:17:32 -0800 (PST) Received: from mail-oa0-x22e.google.com (mail-oa0-x22e.google.com [IPv6:2607:f8b0:4003:c02::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 5AA7B1A029D for ; Thu, 13 Feb 2014 09:17:32 -0800 (PST) Received: by mail-oa0-f46.google.com with SMTP id n16so13006437oag.19 for ; Thu, 13 Feb 2014 09:17:31 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type; bh=hG4anqJsNnkb+7j0ZmuvXkbNYKnequ9ILm7RRzUWHe0=; b=dwXxdLRItnP/HnSoSu70IoBvYFlwYj8fRIQSlIUDSELRYRLlfmGq+liqCkiEotfZHm t4b6UrIcIyQVrGCCf3/XfC8dbm1MXg3pL5T2+B7FmPt9gNe+HdiHPOlUL9/1gJDKJdDo dtcQ9GDJkax4VVT8X+aKNe3RQM7gVA/7lQRLM5D3qaQSMQN1oo7ne6fGeCUiOQZ0brwi 61emuqwJOTKencjQ+w6723nl07ehNmakDkiQOOYYKx6vI6zyf0ygvV4u5oGoAY6KoVTV 6/XncmDNjdwSRzKHtdDxCSuoaYB5cKR3uUlPf7P/H3s1+M4X/+rEkYB/6ZKnC0cBmq2A husA== X-Received: by 10.182.19.132 with SMTP id f4mr2219906obe.14.1392311850905; Thu, 13 Feb 2014 09:17:30 -0800 (PST) Received: from [192.168.1.104] (CPE0013100e2c51-CM001cea35caa6.cpe.net.cable.rogers.com. [99.231.3.110]) by mx.google.com with ESMTPSA id qh4sm7254309obc.4.2014.02.13.09.17.27 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 09:17:29 -0800 (PST) Message-ID: <52FCFE1B.6070000@gmail.com> Date: Thu, 13 Feb 2014 12:17:15 -0500 From: Rene Struik User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , Michael StJohns , "dtls-iot@ietf.org" References: <52FAFD52.2060907@nthpermutation.com> <52FCDE53.5050906@gmail.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------080001020104020609040007" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:17:37 -0000 This is a multi-part message in MIME format. --------------080001020104020609040007 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Hi Sandeep: Perhaps, I was not clear. Of course, if a device's signature key gets compromised it affects traffic emanating from that device. It does not impact signed messages sent by another device, though, which was my point. With group keys, key compromise on one device in the key-sharing group compromises the corresponding key for all other members of that group and, thereby, traffic emanating from any group member. (The group key security model is that devices in the group try and not impersonate each other, so that claimed source authentication and actual source authentication collide.) I think you underestimate the capabilities of vendors and those who can complement their skill set (there is an existence proof of those with reasonable, not billionaire aspirations). I hope this helps. Rene On 2/13/2014 10:18 AM, Kumar, Sandeep wrote: > > Dear Rene > > Sure you can help creating the right implementation but in a > multi-vendor setting where one device can compromise the group, you > need to advice all the vendors -- will make you a billionaire ;) > > I do not agree with your statement "with public keys, a private > signature key is shared with one device only, so its compromise > affects that device only and not any other device'. In a multicast > scenario compromising one private key of any sender would be enough > to send control commands to all devices in the group, so it does > affect all devices until that key is revoked. > > Regards > > Sandeep > > *From:*Rene Struik [mailto:rstruik.ext@gmail.com] > *Sent:* Thursday, February 13, 2014 4:02 PM > *To:* Kumar, Sandeep; Michael StJohns; dtls-iot@ietf.org > *Subject:* Re: [Dtls-iot] Compromise numbers for multicast > > Dear Kumar: > > I just wanted to respond to part of your email. > > To-date, state of the art public-key implementations can be done > securely and quite efficiently without imposing undue energy cost for > computations when compared to communication cost, certainly in > hardware. There has been tremendous technical progress the last 15 > years, but unfortunately perceptions of that time do not seem to have > adapted to newer realities since (at least with IETF email traffic). > Please take the quiz in my email to Olaf Bergman on this > (http://www.ietf.org/mail-archive/web/ace/current/msg00226.html -- > excerpted below). > > It is under the control of implementers to do a good job; any > suggestion that they may not be qualified to do so says more about > these implementers than about the technology being implemented. {Happy > to help if you need advise} > > When discussing compromise of keying material, one has to look at > impact: with symmetric group keys, compromise of a group key on any > device of the key-sharing group compromises any traffic secured by any > of them; with public keys, a private signature key is shared with one > device only, so its compromise affects that device only and not any > other device (assuming no inter dependencies in key hierarchy). > > Best regards, Rene > > > > [excerpt of my email as of February 7, 2014 to the ACE mailing list] > > I have a quiz question for you all: > > What is the estimated *total* energy cost of carrying out 30 billion elliptic curve scalar multiplications on RFID-style devices using a best-of-breed hardware only implementation. For simplicity, let us consider 163-bit binary curves. We will ignore any other aspects. > > Answer options: > a) 1 kWh; {10c} > b) 1 thousand kWh; > c) 1 million kWh; > d) 1 billion kWh. > > There are no prizes. However, I hope this puts the contribution that best-of-breed crypto computations make to global warming (vs. the contribution hereto of email traffic regarding the ACE charter and activities) into perspective. > > Note: This question was triggered by Cisco's and Intel's forecast that by 2020 there would be 30 billion interconnected objects swarming the planet. > > Best regards, Rene > > > > On 2/13/2014 8:49 AM, Kumar, Sandeep wrote: > > Dear Mike > > A good characterization of the inherent difficulty of enabling > multicast security. Even assuming that the multicast security was > based on public keys in a multiple sender group, which is often > the case in IoT, then based on your Pnode of .1%, a group with 10 > senders with private key has a 1% mesh probability compromise (it > is enough to compromise any one of the senders). Considering that > public-key based crypto is much more side-channel leaky and often > hard for developers to get it right compared to directly using the > AES co-processor available in most 802.15.4 chips, the Pnode > probability is going to be much more higher. > > Like every building block, the risks associated with compromise > of a node need to be taken carefully into account, especially with > multicast that risk goes exponentially as you show. Therefore as > you mention a limit to group sizes and additional mitigations need > to be in place. Public key in itself will not provide that > mitigation, it may actually worsen the situation by making DoS > easier by tying up constrained devices in heavy computation. One > has to look at the deployment scenario, perform a risk analysis > identifying the threats, and make a solid design to eliminate > those risks. Although you are right and one should not use this > building block in all deployments/use cases, we also firmly > believe that the current approach can be an effective building > block for reducing risks in many practical scenarios. Other > complementary solutions may need to be created and one solution is > not going to solve all problems. > > Regards > > Sandeep , Sye, Oscar > > *From:*dtls-iot [mailto:dtls-iot-bounces@ietf.org] *On Behalf Of > *Michael StJohns > *Sent:* Wednesday, February 12, 2014 5:49 AM > *To:* dtls-iot@ietf.org > *Subject:* [Dtls-iot] Compromise numbers for multicast > > I was trying to figure out a way of expressing the issues with > shared group symmetric key multicast security and the dangers of > not properly constraining the size of the multicast group that > shares a single key. I came up with the table below. > > The following table is read with the number of nodes down along > the left side, and the probability of any one given node being > "compromisable" running along the top. The intersection is the > probability of the multicast mesh being compromised. > > The formula is 1-((1-Pnode)^numNodes) where Pnode is the > probability of a given node being compromisable. > > For the IOT constrained node model, I'm generally considering a > node compromisable if it is physically accessible to an attacker. > It *may* also be compromisable if its accessible via RF (e.g. > stack smashing attacks etc). The compromise I care about is an > extraction attack on the group key as that gives an attacker the > ability to masquerade as any node in the mesh, eavesdrop on any > traffic, and insert traffic at will. > > So in a mesh of 250 nodes, if there's a .1% chance that any given > node is compromisable, the probability of a mesh compromise is > 22.13%. But I would guess that the per node percentage will > probably be closer to 1% or greater given the wide set of devices, > protections and implementation strategies. > > This is no better than a swag, and it's hard to characterize the > per node probability of compromise given the vast scope of IOT and > the huge possible difference between the least and most capable > nodes in a multicast group. That said, taking 1% probability of > mesh compromise as an arbitrary acceptable high water mark and > .01% as an arbitrary Pnode, I wouldn't use shared key multicast > security for anything over a group of 100 nodes and that only for > low sensitivity applications. If we're talking a Pnode of .1%, > that falls to about 10 nodes. With a Pnode of 1%, that falls to > about 2 nodes. > > The mitigations for these (physically separate network, hardware > security module, physical protections) are mostly not going to be > available for constrained nodes, and the effective Pnode for the > whole mesh is the MIN() of all of the Pnode's of the mesh (weakest > link issue). > > Mike > > > > > > > 5.000000% > > > > 1.000000% > > > > 0.100000% > > > > 0.010000% > > > > 0.001000% > > > > 5 > > > > 22.62% > > > > 4.90% > > > > 0.50% > > > > 0.05% > > > > 0.00% > > > > 20 > > > > 64.15% > > > > 18.21% > > > > 1.98% > > > > 0.20% > > > > 0.02% > > > > 100 > > > > 99.41% > > > > 63.40% > > > > 9.52% > > > > 1.00% > > > > 0.10% > > > > 250 > > > > 100.00% > > > > 91.89% > > > > 22.13% > > > > 2.47% > > > > 0.25% > > > > 500 > > > > 100.00% > > > > 99.34% > > > > 39.36% > > > > 4.88% > > > > 0.50% > > > > 1000 > > > > 100.00% > > > > 100.00% > > > > 63.23% > > > > 9.52% > > > > 1.00% > > > > 2500 > > > > 100.00% > > > > 100.00% > > > > 91.80% > > > > 22.12% > > > > 2.47% > > > > 5000 > > > > 100.00% > > > > 100.00% > > > > 99.33% > > > > 39.35% > > > > 4.88% > > > > 10000 > > > > 100.00% > > > > 100.00% > > > > 100.00% > > > > 63.21% > > > > 9.52% > > > > > > > > > > > ------------------------------------------------------------------------ > > 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. > > > > _______________________________________________ > > dtls-iot mailing list > > dtls-iot@ietf.org > > https://www.ietf.org/mailman/listinfo/dtls-iot > > > > > -- > email:rstruik.ext@gmail.com | Skype: rstruik > cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 -- email: rstruik.ext@gmail.com | Skype: rstruik cell: +1 (647) 867-5658 | US: +1 (415) 690-7363 --------------080001020104020609040007 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
Hi Sandeep:

Perhaps, I was not clear. Of course, if a device's signature key gets compromised it affects traffic emanating from that device. It does not impact signed messages sent by another device, though, which was my point. With group keys, key compromise on one device in the key-sharing group compromises the corresponding key for all other members of that group and, thereby, traffic emanating from any group member. (The group key security model is that devices in the group try and not impersonate each other, so that claimed source authentication and actual source authentication collide.)

I think you underestimate the capabilities of vendors and those who can complement their skill set (there is an existence proof of those with reasonable, not billionaire aspirations).

I hope this helps.

Rene

On 2/13/2014 10:18 AM, Kumar, Sandeep wrote:

Dear Rene

 

Sure you can help creating the right implementation but in a multi-vendor setting where one device can compromise the group, you need to advice all the vendors – will make you a billionaire ;)

 

I do not agree with your statement “with public keys, a private signature key is shared with one device only, so its compromise affects that device only and not any other device’. In a multicast scenario compromising one private key of  any sender would be enough to send control commands to all devices in the group, so it does affect all devices until that key is revoked.

 

Regards

Sandeep

 

From: Rene Struik [mailto:rstruik.ext@gmail.com]
Sent: Thursday, February 13, 2014 4:02 PM
To: Kumar, Sandeep; Michael StJohns; dtls-iot@ietf.org
Subject: Re: [Dtls-iot] Compromise numbers for multicast

 

Dear Kumar:

I just wanted to respond to part of your email.

To-date, state of the art public-key implementations can be done securely and quite efficiently without imposing undue energy cost for computations when compared to communication cost, certainly in hardware. There has been tremendous technical progress the last 15 years, but unfortunately perceptions of that time do not seem to have adapted to newer realities since (at least with IETF email traffic). Please take the quiz in my email to Olaf Bergman on this (http://www.ietf.org/mail-archive/web/ace/current/msg00226.html  -- excerpted below).

It is under the control of implementers to do a good job; any suggestion that they may not be qualified to do so says more about these implementers than about the technology being implemented. {Happy to help if you need advise}

When discussing compromise of keying material, one has to look at impact: with symmetric group keys, compromise of a group key on any device of the key-sharing group compromises any traffic secured by any of them; with public keys, a private signature key is shared with one device only, so its compromise affects that device only and not any other device (assuming no inter dependencies in key hierarchy).

Best regards, Rene 

 
 
[excerpt of my email as of February 7, 2014 to the ACE mailing list]
 
I have a quiz question for you all:
 
What is the estimated *total* energy cost of carrying out 30 billion elliptic curve scalar multiplications on RFID-style devices using a best-of-breed hardware only implementation. For simplicity, let us consider 163-bit binary curves. We will ignore any other aspects.
 
Answer options:
a) 1 kWh; {10c}
b) 1 thousand kWh;
c) 1 million kWh;
d) 1 billion kWh.
 
There are no prizes. However, I hope this puts the contribution that best-of-breed crypto computations make to global warming (vs. the contribution hereto of email traffic regarding the ACE charter and activities) into perspective.
 
Note: This question was triggered by Cisco's and Intel's forecast that by 2020 there would be 30 billion interconnected objects swarming the planet.
 
Best regards, Rene



On 2/13/2014 8:49 AM, Kumar, Sandeep wrote:

Dear Mike

 

A good characterization of the inherent difficulty of enabling multicast security. Even assuming that the multicast security was based on public keys in a multiple sender group, which is often the case in IoT, then based on your  Pnode of .1%, a group with 10 senders with private key has a 1% mesh probability compromise (it is enough to compromise any one of the senders). Considering that public-key based crypto is much  more side-channel leaky and often hard for developers to get it right compared to directly using the AES co-processor available in most 802.15.4 chips, the Pnode probability is going to be much more higher.

 

Like every building block, the risks associated  with compromise of a node need to be taken carefully into account, especially with multicast that risk goes exponentially as you show. Therefore as you mention a limit to group sizes and additional mitigations need to be in place. Public key in itself will not provide that mitigation, it may actually worsen the situation by making DoS easier by tying up constrained devices in heavy computation. One has to look at the deployment scenario, perform a risk analysis identifying the threats, and make a solid design to eliminate those risks. Although you are right and one should not use this building block in all deployments/use cases, we also firmly believe that the current approach can be an effective building block for reducing risks in many practical scenarios. Other complementary solutions may need to be created and one solution is not going to solve all problems.

 

Regards

Sandeep , Sye, Oscar

 

 

From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Michael StJohns
Sent: Wednesday, February 12, 2014 5:49 AM
To: dtls-iot@ietf.org
Subject: [Dtls-iot] Compromise numbers for multicast

 

I was trying to figure out a way of expressing the issues with shared group symmetric key multicast security and the dangers of not properly constraining the size of the multicast group that shares a single key.  I came up with the table below.

The following  table is read with the number of nodes down along the left side, and the probability of any one given node being "compromisable" running along the top.  The intersection is the probability of the multicast mesh being compromised.

The formula is 1-((1-Pnode)^numNodes) where Pnode is the probability of a given node being compromisable.

For the IOT constrained node model, I'm generally considering a node compromisable if it is physically accessible to an attacker.  It *may* also be compromisable if its accessible via RF (e.g. stack smashing attacks etc).  The compromise I care about is an extraction attack on the group key as that gives an attacker the ability to masquerade as any node in the mesh, eavesdrop on any traffic, and insert traffic at will.

So in a mesh of 250 nodes, if there's a .1% chance that any given node is compromisable, the probability of a mesh compromise is 22.13%.  But I would guess that the per node percentage will probably be closer to 1% or greater given the wide set of devices, protections and implementation strategies.

This is no better than a swag, and it's hard to characterize the per node probability of compromise given the vast scope of IOT and the huge possible difference between the least and most capable nodes in a multicast group.  That said, taking 1% probability of mesh compromise as an arbitrary acceptable high water mark and .01% as an arbitrary Pnode, I wouldn't use shared key multicast security for anything over a group of 100 nodes and that only for low sensitivity applications.  If we're talking a Pnode of .1%, that falls to about 10 nodes.  With a Pnode of 1%, that falls to about 2 nodes.

The mitigations for these (physically separate network, hardware security module, physical protections) are mostly not going to be available for constrained nodes, and the effective Pnode for the whole mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue).

Mike




 

5.000000%

1.000000%

0.100000%

0.010000%

0.001000%

5

22.62%

4.90%

0.50%

0.05%

0.00%

20

64.15%

18.21%

1.98%

0.20%

0.02%

100

99.41%

63.40%

9.52%

1.00%

0.10%

250

100.00%

91.89%

22.13%

2.47%

0.25%

500

100.00%

99.34%

39.36%

4.88%

0.50%

1000

100.00%

100.00%

63.23%

9.52%

1.00%

2500

100.00%

100.00%

91.80%

22.12%

2.47%

5000

100.00%

100.00%

99.33%

39.35%

4.88%

10000

100.00%

100.00%

100.00%

63.21%

9.52%







 

 

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.



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




-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363


-- 
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363
--------------080001020104020609040007-- From nobody Thu Feb 13 09:56:41 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 E73C31A0385 for ; Thu, 13 Feb 2014 09:56:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UxAkBbLrr-zp for ; Thu, 13 Feb 2014 09:56:38 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 224F61A02A7 for ; Thu, 13 Feb 2014 09:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1DHuRit012882; Thu, 13 Feb 2014 18:56:27 +0100 (CET) Received: from [192.168.217.101] (p548904E0.dip0.t-ipconnect.de [84.137.4.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id CE8A1F5F; Thu, 13 Feb 2014 18:56:26 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <52FAFD52.2060907@nthpermutation.com> Date: Thu, 13 Feb 2014 18:56:25 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52FAFD52.2060907@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/-g8cWC04snZ9J0PhhbVNzDPHLnM Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 17:56:40 -0000 On 12 Feb 2014, at 05:49, Michael StJohns = wrote: > I was trying to figure out a way of expressing the issues with shared = group symmetric key multicast security and the dangers of not properly = constraining the size of the multicast group that shares a single key. = I came up with the table below. Nice demonstration of the issue with sharing keys in a group. It clearly proves that pay TV is impossible :-) Now, of course, the table only would make literal sense if the = probabilities of compromise were uncorrelated, which is never the case. You either have an attacker, and then the number of compromisable = instances is almost irrelevant (although the ease of getting one may = increase with the number, the increase is rarely as pronounced). Or you don=92t have an attacker, and then you are safe (!). More interesting is the damage a single compromised key can do, which = may be linear to the group size, and which may influence the likelihood = of an attacker being interested. The group size is one important factor influencing the risk/cost = relationship. But questions of threat model, incentive for compromise etc. are usually = more important. The most important guideline may be to avoid putting large chests of = gold behind some thin security. Other advice, such as enabling regular (and thus necessarily cheap) = rekeying, may also be useful. For controlling the lights in my living room, a symmetric shared key is = entirely adequate. Gr=FC=DFe, Carsten From nobody Thu Feb 13 10:34:13 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 C15D21A03D7 for ; Thu, 13 Feb 2014 10:34:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id knnUC6suVjs9 for ; Thu, 13 Feb 2014 10:34:07 -0800 (PST) Received: from mail-qa0-f52.google.com (mail-qa0-f52.google.com [209.85.216.52]) by ietfa.amsl.com (Postfix) with ESMTP id 47BB41A03C8 for ; Thu, 13 Feb 2014 10:34:07 -0800 (PST) Received: by mail-qa0-f52.google.com with SMTP id j15so16989236qaq.11 for ; Thu, 13 Feb 2014 10:34:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=p60PDI+nsaOo7GcNpltDIzZDQWiI44nqh4gfM8am9d4=; b=UtqtfVVbbMWGPZntT1xWRxOQOupf3pImX2kXElCO+cRLBp3EHwGH15nq6B+UrahQjL NKRIxQ0HOHtd1qDuTPXQjX/SNByakWpztxOm6KxMFLG7pSjMWh/1T7nOU190d7wZxVUa WNm6MbOzSyNzWINgNVwPicfL5kqVxu3rCQjFv8RA4u0Wi45IzXR3xd109eRCtSK6xC3N LaRZ1Vdumv0TNx5mnXyBBJX4St5xHhQhI0+lz/cMOcUUDiEuCsdxl/4fCHVoACJjG7ce EyA4RNpL67pk3LalXdjp7etut4fp8Ls4ITwkHfi+czxL58ZBi8x7TJOmfuCcjNvmAnjP J+Jg== X-Gm-Message-State: ALoCoQlS4/3sMOpP0zHXKz7bKJZ32DWM2839VQWtlDiQvC5D+rldNPiZXKv3/rY1UbcvIqxRUY7H X-Received: by 10.140.40.5 with SMTP id w5mr4845965qgw.65.1392316445914; Thu, 13 Feb 2014 10:34:05 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id b12sm7632556qag.23.2014.02.13.10.34.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 10:34:05 -0800 (PST) Message-ID: <52FD102F.5040907@nthpermutation.com> Date: Thu, 13 Feb 2014 13:34:23 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carsten Bormann References: <52FAFD52.2060907@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/KIPcdigXMuDmptSMqArAI-TAtDg Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 18:34:10 -0000 On 2/13/2014 12:56 PM, Carsten Bormann wrote: > Nice demonstration of the issue with sharing keys in a group. > It clearly proves that pay TV is impossible:-) Given the number of times pay tv has been compromised, I rest my case. Seriously though, I also said: > The mitigations for these (physically separate network, hardware > security module, physical protections) are mostly not going to be > available for constrained nodes, and the effective Pnode for the whole > mesh is the MIN() of all of the Pnode's of the mesh (weakest link issue). In the cable tv case, the value of data protected allows them to provide a hardware security module (e.g. smart card, smart chip, cablecard, set top box) as part of the cost of doing business. They also make this work by having a single sender, non-control system with fairly rapidly rotating traffic keys. > Now, of course, the table only would make literal sense if the probabilities of compromise were uncorrelated, which is never the case. > You either have an attacker, and then the number of compromisable instances is almost irrelevant (although the ease of getting one may increase with the number, the increase is rarely as pronounced). As I explained, I suggested that Pnode was a rough estimate of the average compromisability of the nodes of the mesh and was nothing more than a swag to illustrate the issues with the increase of mesh size. > Or you don’t have an attacker, and then you are safe (!). Pattacker approaches 100% as the number of installations reaches an interesting number, as the hackers write script kiddy kits and as the system transitions from a security savvy installer to an IT security illiterate building manager. > More interesting is the damage a single compromised key can do, which may be linear to the group size, and which may influence the likelihood of an attacker being interested. > > The group size is one important factor influencing the risk/cost relationship. > But questions of threat model, incentive for compromise etc. are usually more important. The issue here is that we're trying to write general purpose TLS based IOT profiles. Given that a single general purpose IOT mesh can be 100s of 1000s of nodes, its pretty clear to me that ANY symmetric key approach is not going to be generally applicable. > The most important guideline may be to avoid putting large chests of gold behind some thin security. > Other advice, such as enabling regular (and thus necessarily cheap) rekeying, may also be useful. We (IETF) write protocols and applicability statements. We can provide constraints (e.g. don't use this on any mesh that's not Carsten's living room and only if there are 5 lights or less), but given that people tend to ignore the designed applicability of our protocols (e.g. DNS being used as a swiss army knife), it's unclear the constraints will be strong enough or provide enough weight of consideration for the possible implementers. We mostly don't write usage guidance - the closest we come is the security considerations section, and it would kind of defeat the purpose to write "don't use this on meshes in size > 5 without physical security mitigations" > > For controlling the lights in my living room, a symmetric shared key is entirely adequate. For controlling the lights in your living room, the link-layer security to prevent strangers from inserting traffic in your RF mesh is entirely adequate. And that's not a TLS function. Mike From nobody Thu Feb 13 12:16: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 DBD361A0489 for ; Thu, 13 Feb 2014 12:16:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tlUwEEbdJufG for ; Thu, 13 Feb 2014 12:16:28 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 4B4E51A0454 for ; Thu, 13 Feb 2014 12:16:28 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1DKGLkW024275; Thu, 13 Feb 2014 21:16:21 +0100 (CET) Received: from [192.168.217.101] (p548904E0.dip0.t-ipconnect.de [84.137.4.224]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id E38B7FDB; Thu, 13 Feb 2014 21:16:20 +0100 (CET) Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) Content-Type: text/plain; charset=windows-1252 From: Carsten Bormann In-Reply-To: <52FD102F.5040907@nthpermutation.com> Date: Thu, 13 Feb 2014 21:16:18 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <52FAFD52.2060907@nthpermutation.com> <52FD102F.5040907@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/yq5AEVnI-nc1hseLLuiRQRVlAVI Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 20:16:30 -0000 I think we are in violent agreement, up to here: > The issue here is that we're trying to write general purpose TLS based = IOT profiles. Given that a single general purpose IOT mesh can be 100s = of 1000s of nodes, its pretty clear to me that ANY symmetric key = approach is not going to be generally applicable. So far, this is proof by lack of imagination. (But, clearly, we=92d have to substantiate =93ANY symmetric key = approach=94 to prove the opposite.) >> For controlling the lights in my living room, a symmetric shared key = is entirely adequate. > For controlling the lights in your living room, the link-layer = security to prevent strangers from inserting traffic in your RF mesh is = entirely adequate. And that's not a TLS function. Here I completely disagree:=20 We have to do whatever we can to get rid of the current consumer = electronics notion that the keying protecting access to the home network = also is the perfect means to authorize control over everything in the = entire home. Gr=FC=DFe, Carsten From nobody Thu Feb 13 15:36:56 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 2BE4C1A0531 for ; Thu, 13 Feb 2014 15:36:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VmQWoyzZTzZ0 for ; Thu, 13 Feb 2014 15:36:53 -0800 (PST) Received: from mail-qa0-f54.google.com (mail-qa0-f54.google.com [209.85.216.54]) by ietfa.amsl.com (Postfix) with ESMTP id 22BD31A052C for ; Thu, 13 Feb 2014 15:36:53 -0800 (PST) Received: by mail-qa0-f54.google.com with SMTP id i13so17325389qae.27 for ; Thu, 13 Feb 2014 15:36:51 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type :content-transfer-encoding; bh=F2zY34GlZbWv75GDFQuYwiKpQZ3OQd1rrX8Vo5GJB6U=; b=FOVSiVjdFeUktjTO+3kuwGvuSOs2jrgYy7fpfPBdWC0HHcox1RWg1Zf/9Is3QOu0Sb msKsxW6VVRKpVc7gNbsd5yr0Nl8Hxbp7OolA8RI7FxJK4u8zKx95bWl/ZXgVn6zVbWim xdK56rNkHlTxyteiU1zXPlcP3UQD/Xaf8Na/Y0xpcdi6/FNEuhviLxWRhAItDGHKUxTx sk5WQsFgtHSLAtDyHTBVl/8QnMVPzKK+5P6iEf907b1r6IBjAl3h0TxpUwZxCBWvSTQv fW25PlxTi0CzbgTx5mBxU3SlPUC+BlTZLR1R9ComtIQseS8+c6sf90zEnKY3091L7Cm8 Xkbw== X-Gm-Message-State: ALoCoQnlWTieCloAoe+Nwzih1nvl5tMQDwMcKrepQTiZdzjcJ9croc6qUHF6DX0243cPA/WCIidJ X-Received: by 10.229.179.69 with SMTP id bp5mr7534600qcb.17.1392334611652; Thu, 13 Feb 2014 15:36:51 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id h12sm9953785qar.14.2014.02.13.15.36.51 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 13 Feb 2014 15:36:51 -0800 (PST) Message-ID: <52FD5725.3030703@nthpermutation.com> Date: Thu, 13 Feb 2014 18:37:09 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: Carsten Bormann References: <52FAFD52.2060907@nthpermutation.com> <52FD102F.5040907@nthpermutation.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Xd9piEVQISfHdL88LMAm80tYMLk Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] Compromise numbers for multicast X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Feb 2014 23:36:55 -0000 On 2/13/2014 3:16 PM, Carsten Bormann wrote: > I think we are in violent agreement, up to here: > >> The issue here is that we're trying to write general purpose TLS based IOT profiles. Given that a single general purpose IOT mesh can be 100s of 1000s of nodes, its pretty clear to me that ANY symmetric key approach is not going to be generally applicable. > So far, this is proof by lack of imagination. > (But, clearly, we’d have to substantiate “ANY symmetric key approach” to prove the opposite.) No, this is proof by statistical analysis. Assuming the figure of merit number of 1% chance of compromise of the mesh, with a mesh of 100000 devices, you'd need an average Pnode of less than .00001%. If you believe its possible to build a device class that has an average Pnode < .00001% then I have a bridge to sell you. Cash please! Small bills. Again, this (as does my original email) assumes NO mitigation in the form of hardware security modules, physically protected nodes and physically isolated nodes. > >>> For controlling the lights in my living room, a symmetric shared key is entirely adequate. >> For controlling the lights in your living room, the link-layer security to prevent strangers from inserting traffic in your RF mesh is entirely adequate. And that's not a TLS function. > Here I completely disagree: > We have to do whatever we can to get rid of the current consumer electronics notion that the keying protecting access to the home network also is the perfect means to authorize control over everything in the entire home. We have to do whatever we can to understand that multicast DTLS as described in the current document with a common shared key does not provide any additional security over that provided by the link-layer. It's an investment that looks like it provides some additional security, but it really and truly doesn't. Here's the underlying problem: cProtection < vData < cAttack. Cost effective security needs to have this set of relationships. You don't want to pay more for protection, than the value of what you're protecting. You don't want to pay more for protection than what it will cost the attacker to break in, and you don't want the value of the data to be more than what it costs the attacker to get it. In a mesh with a single key system, vData becomes SUM(vData) - the total value of what's being protected by the single key. As you add more nodes, SUM(vData) increases. Eventually it becomes a really interesting target for the attacker. That suggests as the number of nodes protected by the same key increases, you need to increase your cProtection spending past that appropriate for DICE. > > Grüße, Carsten > From nobody Fri Feb 14 07:24:56 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 4DABE1A02BF for ; Fri, 14 Feb 2014 07:24:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e4ZP6tErZ-fl for ; Fri, 14 Feb 2014 07:24:51 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 21B9F1A0284 for ; Fri, 14 Feb 2014 07:24:50 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1EFOg5a019132 for ; Fri, 14 Feb 2014 16:24:42 +0100 (CET) Received: from eduroam-pool7-0484.wlan.uni-bremen.de (eduroam-pool7-0484.wlan.uni-bremen.de [134.102.113.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 741A2473; Fri, 14 Feb 2014 16:24:42 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann Date: Fri, 14 Feb 2014 16:24:41 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> To: dtls-iot@ietf.org X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/bJIVeT980QQCAwq_FnDzvcwsUB4 Subject: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy 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 Feb 2014 15:24:53 -0000 Lars and I have written up some work that he did on a cipher suite that = is based on the AES-CCM crypto we often have in constrained devices, and = on PSK, but does provide forward secrecy. The main part of the document is pretty straightforward, I think. In = DICE, we should think about whether we need this and whether the choices = made here are the right ones. If we agree, this could then go on to the = appropriate places to define a cipher suite. There is also a more radical proposal in the document: in AES-CCM, = SHA-256 is only used in the PRF, and for this kind of application, it = would be nice to be able to save those 2 KiB or so. So we define a = CMAC-based PRF as a potential alternative. Of course, we don=92t even = play cryptographers on TV, so this part is just a strawman that would = need some significant scrutiny. Again, DICE might be a forum to = consider whether this is worth pursuing. Gr=FC=DFe, Carsten Begin forwarded message: > From: internet-drafts@ietf.org > Subject: I-D Action: draft-schmertmann-dice-ccm-psk-pfs-00.txt > Date: 14 Feb 2014 16:10:44 +0100 > To: i-d-announce@ietf.org > Reply-To: internet-drafts@ietf.org >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. >=20 >=20 > Title : ECDHE-PSK AES-CCM Cipher Suites with Forward = Secrecy for Transport Layer Security (TLS) > Authors : Lars Schmertmann > Carsten Bormann > Filename : draft-schmertmann-dice-ccm-psk-pfs-00.txt > Pages : 7 > Date : 2014-02-14 >=20 > Abstract: > RFC 6655 describes the use of the Advanced Encryption Standard (AES) > in the Counter with Cipher Block Chaining - Message Authentication > Code (CBC-MAC) Mode (CCM) of operation within Transport Layer > Security (TLS) and Datagram TLS (DTLS) to provide confidentiality = and > data origin authentication. The AES-CCM algorithm is amenable to > compact implementations, making it suitable for constrained > environments. It has been chosen as one of the preferred cipher > suites for use with DTLS in the Constrained Application Protocol, > CoAP. >=20 > The present document defines additional cipher suites that provide > forward secrecy. It also discusses an option to replace the Hash- > based PRF in RFC 6655 by CMAC, reducing the number of cryptographic > primitives required for implementation. (The intention is that the > option is either chosen or not chosen before this document is = agreed, > not that both options are defined.) >=20 > This document is initially addressed at the DICE working group in > order to build consensus that there is an actual gap to be filled = and > about the technical parameters of a solution for that gap. Once = this > is agreed, the usual path for agreeing a cipher suite will need to = be > taken. >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-schmertmann-dice-ccm-psk-pfs/ >=20 > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-schmertmann-dice-ccm-psk-pfs-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of = submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 From nobody Fri Feb 14 07:39:28 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 C3C8E1A026E for ; Fri, 14 Feb 2014 07:39:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Od4AssAFG0yc for ; Fri, 14 Feb 2014 07:39:24 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 514361A02BA for ; Fri, 14 Feb 2014 07:39:21 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1EFdDRR016308 for ; Fri, 14 Feb 2014 16:39:13 +0100 (CET) Received: from eduroam-pool7-0484.wlan.uni-bremen.de (eduroam-pool7-0484.wlan.uni-bremen.de [134.102.113.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B4EB483; Fri, 14 Feb 2014 16:39:13 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: Date: Fri, 14 Feb 2014 16:39:12 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <68521793-1C71-41CE-9A52-CA9A382189BD@tzi.org> References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> To: dtls-iot@ietf.org X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/E2Kt7_iMjSE6vij0eF5-sNgXUjg Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy 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 Feb 2014 15:39:26 -0000 On 14 Feb 2014, at 16:24, Carsten Bormann wrote: > In DICE, we should think about whether we need this (See also = http://tools.ietf.org/html/draft-hartke-dice-profile-03#section-10 for = some motivation for this.) Gr=FC=DFe, Carsten From nobody Fri Feb 14 08:14: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 03BD21A032F for ; Fri, 14 Feb 2014 08:14:26 -0800 (PST) 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 l_aniFu6dOl5 for ; Fri, 14 Feb 2014 08:14:23 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe001.messaging.microsoft.com [207.46.163.24]) by ietfa.amsl.com (Postfix) with ESMTP id 8408D1A030A for ; Fri, 14 Feb 2014 08:13:56 -0800 (PST) Received: from mail32-co9-R.bigfish.com (10.236.132.247) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.22; Fri, 14 Feb 2014 16:13:55 +0000 Received: from mail32-co9 (localhost [127.0.0.1]) by mail32-co9-R.bigfish.com (Postfix) with ESMTP id F0A691602B3 for ; Fri, 14 Feb 2014 16:13:54 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -30 X-BigFish: VPS-30(z579ehz15d6O9371Ic89bh936eI1be0I542I9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275dh1de097h186068hz2dh109h2a8h839h93fhd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24d7h2516h2545h255eh1155h) Received: from mail32-co9 (localhost.localdomain [127.0.0.1]) by mail32-co9 (MessageSwitch) id 1392394433452716_8195; Fri, 14 Feb 2014 16:13:53 +0000 (UTC) Received: from CO9EHSMHS009.bigfish.com (unknown [10.236.132.253]) by mail32-co9.bigfish.com (Postfix) with ESMTP id 5ECCB2E00D3 for ; Fri, 14 Feb 2014 16:13:53 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS009.bigfish.com (10.236.130.19) with Microsoft SMTP Server (TLS) id 14.16.227.3; Fri, 14 Feb 2014 16:13:48 +0000 Received: from 011-DB3MMR1-013.MGDPHG.emi.philips.com (10.128.28.97) by 011-DB3MMR1-005.MGDPHG.emi.philips.com (10.128.28.55) with Microsoft SMTP Server (TLS) id 14.3.174.2; Fri, 14 Feb 2014 16:13:31 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.200]) by 011-DB3MMR1-013.MGDPHG.emi.philips.com ([10.128.28.97]) with mapi id 14.03.0174.002; Fri, 14 Feb 2014 16:13:30 +0000 From: "Kumar, Sandeep" To: "dtls-iot@ietf.org" Thread-Topic: New Version Notification for draft-keoh-dice-multicast-security-05.txt Thread-Index: AQHPKZ8cm5Vu+w2Q+U2vazDhmeaxlJq063pA Date: Fri, 14 Feb 2014 16:13:30 +0000 Message-ID: References: <20140214160858.5956.3525.idtracker@ietfa.amsl.com> In-Reply-To: <20140214160858.5956.3525.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [194.171.252.106] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: philips.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/D4R2Dhhqzb8xZUX92s_DSXLH2kg Subject: [Dtls-iot] FW: New Version Notification for draft-keoh-dice-multicast-security-05.txt 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 Feb 2014 16:14:26 -0000 RGVhciBhbGwNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQgaGFzIGJlZW4gc3VibWl0dGVk IHRoYXQgdGFrZXMgTWlrZeKAmXMgY29tbWVudHMgaW50byBjb25zaWRlcmF0aW9uIGVzcGVjaWFs bHkgdGhlIGdyb3VwIHNpemVzLg0KDQpJdCBpcyBnb29kIHRvIGNsYXJpZnkgdGhhdCB0aGUgc29s dXRpb24gZGVzY3JpYmVkIGlzIG5vdCBhIGdlbmVyaWMgc29sdXRpb24gdG8gc29sdmUgZXZlcnkg bXVsdGljYXN0IHNlY3VyaXR5IHByb2JsZW0gaW4gSW9UIG9yIHRoZSBJbnRlcm5ldC4gV2UgaGF2 ZSBhIHZlcnkgc3BlY2lmaWMgcHJvYmxlbSBkb21haW4gb2Ygc29tZSBncm91cCBtZW1iZXJzIGJl aW5nIGRpc3RyaWJ1dGVkIGluIG11bHRpcGxlIG1lc2ggKHdpdGggTDIgc2VjdXJpdHkpIHdoaWNo IGFyZSBjb25uZWN0ZWQgdGhyb3VnaCB0aGUgYmFja2JvbmUuIElmIHRoZXkgd2VyZSBsb2NhdGVk IGluIGEgc2luZ2xlIHBoeXNpY2FsIHN1Ym5ldCwgdGhlbiBMMiBzZWN1cml0eSB3b3VsZCBoYXZl IHN1ZmZpY2VkLiBUaGUgaW50ZW50aW9uIGlzIHRvIHByb3ZpZGUgdGhlIHNhbWUgbGV2ZWwgb2Yg TDIgIHNlY3VyaXR5IHRvIHRoaXMgZGlzdHJpYnV0ZWQgZ3JvdXAuIEFueSBzb3VyY2UgYXV0aGVu dGljaXR5IHNvbHV0aW9ucyBhcmUgY29tcGxlbWVudGFyeSBhbmQgY2FuIGJlIGFkZGl0aW9uYWxs eSBkZXNpZ25lZCBhdCB0aGUgYXBwbGljYXRpb24gbGF5ZXIuDQoNCktpbmQgcmVnYXJkcw0KU2Fu ZGVlcA0KDQotLS0tDQpDaGFuZ2VzIGZyb20ga2VvaC0wNCB0byBrZW9oLTA1Og0KDQogICBvICBJ biBzZWN0aW9uIDIuMSwgcmVtb3ZlZCB0aGUgZmlybXdhcmUgdXBncmFkZSB1c2UgY2FzZSBhbmQg Y2xhcmlmaWVkDQogICAgICB0aGUgY29tbWlzc2lvbmluZyB1c2UgY2FzZS4gIFRoZSBsaWdodGlu ZyB1c2UtY2FzZSBleHBhbmRlZCB3aXRoDQogICAgICBzaGFyZWQgYW5kIG11bHRpcGxlIHN1Ym5l dHMgaXNzdWVzLg0KDQogICBvICBJbiBTZWN0aW9uIDIuMiwgKGIpIHJlZHVjZWQgdGhlIGdyb3Vw IHNpemUgdG8gMTAwOyAoaCkgY2xhcmlmaWVkDQogICAgICBkYXRhIHNvdXJjZSBhdXRoZW50aWNp dHkNCg0KICAgbyAgQWRkZWQgbmV3IFNlY3Rpb24gNi4xIChHcm91cCBsZXZlbCBzZWN1cml0eSkg aW4gc2VjdXJpdHkNCiAgICAgIGNvbnNpZGVyYXRpb25zIHRvIG1ha2UgY2xlYXIgdGhlIHJpc2tz IG9mIHRoZSBzaW5nbGUgZ3JvdXAga2V5Lg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcgW21haWx0bzppbnRlcm5ldC1kcmFmdHNA aWV0Zi5vcmddDQpTZW50OiBGcmlkYXksIEZlYnJ1YXJ5IDE0LCAyMDE0IDU6MDkgUE0NClRvOiBL dW1hciwgU2FuZGVlcDsgR2FyY2lhIE1vcmNob24sIE9zY2FyOyBLdW1hciwgU2FuZGVlcDsgU3ll IExvb25nIEtlb2g7IERpamssIEVza287IEdhcmNpYSBNb3JjaG9uLCBPc2NhcjsgRGlqaywgRXNr bzsgQWtiYXIgUmFobWFuOyBTeWUgTG9vbmcgS2VvaDsgQWtiYXIgUmFobWFuDQpTdWJqZWN0OiBO ZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2Vj dXJpdHktMDUudHh0DQoNCg0KQSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWtlb2gtZGljZS1t dWx0aWNhc3Qtc2VjdXJpdHktMDUudHh0DQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk IGJ5IFNhbmRlZXAgUy4gS3VtYXIgYW5kIHBvc3RlZCB0byB0aGUgSUVURiByZXBvc2l0b3J5Lg0K DQpOYW1lOiAgICAgICAgICAgZHJhZnQta2VvaC1kaWNlLW11bHRpY2FzdC1zZWN1cml0eQ0KUmV2 aXNpb246ICAgICAgIDA1DQpUaXRsZTogICAgICAgICAgRFRMUy1iYXNlZCBNdWx0aWNhc3QgU2Vj dXJpdHkgZm9yIExvdy1Qb3dlciBhbmQgTG9zc3kgTmV0d29ya3MgKExMTnMpDQpEb2N1bWVudCBk YXRlOiAgMjAxNC0wMi0xNA0KR3JvdXA6ICAgICAgICAgIEluZGl2aWR1YWwgU3VibWlzc2lvbg0K UGFnZXM6ICAgICAgICAgIDIxDQpVUkw6ICAgICAgICAgICAgaHR0cDovL3d3dy5pZXRmLm9yZy9p bnRlcm5ldC1kcmFmdHMvZHJhZnQta2VvaC1kaWNlLW11bHRpY2FzdC1zZWN1cml0eS0wNS50eHQN ClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1r ZW9oLWRpY2UtbXVsdGljYXN0LXNlY3VyaXR5Lw0KSHRtbGl6ZWQ6ICAgICAgIGh0dHA6Ly90b29s cy5pZXRmLm9yZy9odG1sL2RyYWZ0LWtlb2gtZGljZS1tdWx0aWNhc3Qtc2VjdXJpdHktMDUNCkRp ZmY6ICAgICAgICAgICBodHRwOi8vd3d3LmlldGYub3JnL3JmY2RpZmY/dXJsMj1kcmFmdC1rZW9o LWRpY2UtbXVsdGljYXN0LXNlY3VyaXR5LTA1DQoNCkFic3RyYWN0Og0KICAgVGhlIENvQVAgYW5k IDZMb1dQQU4gc3RhbmRhcmRzIGFyZSBmYXN0IGVtZXJnaW5nIGFzIGtleSBwcm90b2NvbHMgaW4N CiAgIHRoZSBhcmVhIG9mIHJlc291cmNlLWNvbnN0cmFpbmVkIGRldmljZXMuICBTdWNoIElQLWJh c2VkIHN5c3RlbXMgYXJlDQogICBmb3Jlc2VlbiB0byBiZSB1c2VkIGZvciBidWlsZGluZyBhbmQg bGlnaHRpbmcgY29udHJvbCBzeXN0ZW1zIHdoZXJlDQogICB3aXJlbGVzcyBkZXZpY2VzIGludGVy Y29ubmVjdCB3aXRoIGVhY2ggb3RoZXIsIGZvcm1pbmcgbG93LXBvd2VyIGFuZA0KICAgbG9zc3kg bmV0d29ya3MgKExMTnMpLiAgQm90aCBtdWx0aWNhc3QgYW5kIGl0cyBzZWN1cml0eSBhcmUga2V5 IG5lZWRzDQogICBpbiB0aGVzZSBuZXR3b3Jrcy4gIFRoaXMgZHJhZnQgcHJlc2VudHMgYSBtZXRo b2QgZm9yIHNlY3VyaW5nIElQdjYNCiAgIG11bHRpY2FzdCBjb21tdW5pY2F0aW9uIGluIExMTnMg YmFzZWQgb24gdGhlIERUTFMgd2hpY2ggaXMgYWxyZWFkeQ0KICAgc3VwcG9ydGVkIGZvciB1bmlj YXN0IGNvbW11bmljYXRpb24gZm9yIENvQVAgZGV2aWNlcy4gIFRoaXMgZHJhZnQNCiAgIGRlYWxz IHdpdGggdGhlIGFkYXB0YXRpb24gb2YgdGhlIERUTFMgcmVjb3JkIGxheWVyIHRvIHByb3RlY3QN CiAgIG11bHRpY2FzdCBncm91cCBjb21tdW5pY2F0aW9uLCBhc3N1bWluZyB0aGF0IGFsbCBncm91 cCBtZW1iZXJzDQogICBhbHJlYWR5IGhhdmUgdGhlIGdyb3VwIHNlY3VyaXR5IGFzc29jaWF0aW9u IHBhcmFtZXRlcnMgaW4gdGhlaXINCiAgIHBvc3Nlc3Npb24uICBUaGUgYWRhcHRlZCBEVExTIHJl Y29yZCBsYXllciBwcm92aWRlcyBtZXNzYWdlDQogICBjb25maWRlbnRpYWxpdHksIGludGVncml0 eSBhbmQgcmVwbGF5IHByb3RlY3Rpb24gdG8gZ3JvdXAgbWVzc2FnZXMNCiAgIHVzaW5nIHRoZSBn cm91cCBrZXlpbmcgbWF0ZXJpYWwgYmVmb3JlIHNlbmRpbmcgdGhlIG1lc3NhZ2UgdmlhIElQdjYN CiAgIG11bHRpY2FzdCB0byB0aGUgZ3JvdXAuDQoNCg0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQg bWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBmcm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24g dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29s cy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fXw0KVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1lc3Nh Z2UgbWF5IGJlIGNvbmZpZGVudGlhbCBhbmQgbGVnYWxseSBwcm90ZWN0ZWQgdW5kZXIgYXBwbGlj YWJsZSBsYXcuIFRoZSBtZXNzYWdlIGlzIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIGFkZHJlc3Nl ZShzKS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgeW91IGFyZSBoZXJl Ynkgbm90aWZpZWQgdGhhdCBhbnkgdXNlLCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBvciBy ZXByb2R1Y3Rpb24gb2YgdGhpcyBtZXNzYWdlIGlzIHN0cmljdGx5IHByb2hpYml0ZWQgYW5kIG1h eSBiZSB1bmxhd2Z1bC4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxl YXNlIGNvbnRhY3QgdGhlIHNlbmRlciBieSByZXR1cm4gZS1tYWlsIGFuZCBkZXN0cm95IGFsbCBj b3BpZXMgb2YgdGhlIG9yaWdpbmFsIG1lc3NhZ2UuDQo= From nobody Fri Feb 14 08:59:38 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 8A45B1A032F for ; Fri, 14 Feb 2014 08:59:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 26XitSKd-XwE for ; Fri, 14 Feb 2014 08:59:34 -0800 (PST) Received: from hoemail1.alcatel.com (hoemail1.alcatel.com [192.160.6.148]) by ietfa.amsl.com (Postfix) with ESMTP id 397701A0329 for ; Fri, 14 Feb 2014 08:59:34 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by hoemail1.alcatel.com (8.13.8/IER-o) with ESMTP id s1EGxUug021269 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Fri, 14 Feb 2014 10:59:32 -0600 (CST) Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id s1EGxUIY025012 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 14 Feb 2014 17:59:30 +0100 Received: from FR711WXCHMBA08.zeu.alcatel-lucent.com ([169.254.4.236]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.02.0247.003; Fri, 14 Feb 2014 17:59:30 +0100 From: "FOSSATI, Thomas (Thomas)" To: Carsten Bormann , "dtls-iot@ietf.org" Thread-Topic: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy Thread-Index: AQHPKZkbUSvtDCUMu0+tGnVNIMlr45q06EgA Date: Fri, 14 Feb 2014 16:59:30 +0000 Message-ID: References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.40] Content-Type: text/plain; charset="utf-8" Content-ID: <1A42B13FB06B124A9EBAF01DDA91F5C0@exchange.lucent.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/FtWZYnkgatFoizQKZmf6tLC7NYg Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy 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 Feb 2014 16:59:36 -0000 SGkgQ2Fyc3RlbiwNCg0KT24gMTQvMDIvMjAxNCAxNToyNCwgIkNhcnN0ZW4gQm9ybWFubiIgPGNh Ym9AdHppLm9yZz4gd3JvdGU6DQo+VGhlcmUgaXMgYWxzbyBhIG1vcmUgcmFkaWNhbCBwcm9wb3Nh bCBpbiB0aGUgZG9jdW1lbnQ6IGluIEFFUy1DQ00sDQo+U0hBLTI1NiBpcyBvbmx5IHVzZWQgaW4g dGhlIFBSRiwgYW5kIGZvciB0aGlzIGtpbmQgb2YgYXBwbGljYXRpb24sIGl0DQo+d291bGQgYmUg bmljZSB0byBiZSBhYmxlIHRvIHNhdmUgdGhvc2UgMiBLaUIgb3Igc28uICBTbyB3ZSBkZWZpbmUg YQ0KPkNNQUMtYmFzZWQgUFJGIGFzIGEgcG90ZW50aWFsIGFsdGVybmF0aXZlLiAgT2YgY291cnNl LCB3ZSBkb27igJl0IGV2ZW4gcGxheQ0KPmNyeXB0b2dyYXBoZXJzIG9uIFRWLCBzbyB0aGlzIHBh cnQgaXMganVzdCBhIHN0cmF3bWFuIHRoYXQgd291bGQgbmVlZA0KPnNvbWUgc2lnbmlmaWNhbnQg c2NydXRpbnkuICBBZ2FpbiwgRElDRSBtaWdodCBiZSBhIGZvcnVtIHRvIGNvbnNpZGVyDQo+d2hl dGhlciB0aGlzIGlzIHdvcnRoIHB1cnN1aW5nLg0KDQphbiBldmVuIGRlZXBlciBzY3J1dGlueSBm b3IgdGhlIOKAnHJhZGljYWzigJ0gYml0IGluIHlvdXIgcHJvcG9zYWwgY291bGQgY29tZQ0KZnJv bSBjZnJnQGlydGYub3JnLg0KDQpJIHRoaW5rIGl04oCZZCBiZSB3b3J0aCBkcm9wcGluZyBhbiBl bWFpbCB0aGVyZSBhcyB3ZWxsLg0KDQpDaGVlcnMNCg0K From nobody Fri Feb 14 11:50:50 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 B82A41A0384 for ; Fri, 14 Feb 2014 11:50:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7SpNeDQ14kzu for ; Fri, 14 Feb 2014 11:50:39 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 7D00D1A03D2 for ; Fri, 14 Feb 2014 11:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1EJmwgn016513 for ; Fri, 14 Feb 2014 20:48:58 +0100 (CET) Received: from eduroam-pool7-0484.wlan.uni-bremen.de (eduroam-pool7-0484.wlan.uni-bremen.de [134.102.113.228]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 8A3CE54D; Fri, 14 Feb 2014 20:48:58 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann Date: Fri, 14 Feb 2014 20:48:57 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214185408.28510.55973.idtracker@ietfa.amsl.com> To: dtls-iot@ietf.org X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/IfqokgMpKf36SiJRSHRBki74p2A Subject: [Dtls-iot] DTLS over CoAP 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 Feb 2014 19:50:41 -0000 Lars has implemented Klaus=92/Olaf=92s draft about transporting DTLS = handshake messages in CoAP, combining it with their header compression = ideas. This is described in the below draft, along with some modifications of = the spec. As a specification, this is not fully baked yet, but maybe we should be = discussing the points under =93Discussion=94 first before nailing the = rest of this down. Gr=FC=DFe, Carsten Begin forwarded message: > From: internet-drafts@ietf.org > Subject: New Version Notification for = draft-schmertmann-dice-codtls-00.txt > Date: 14 Feb 2014 19:54:08 +0100 > To: "Klaus Hartke" , Klaus Hartke , = "Dr. Carsten Bormann" , Lars Schmertmann , = Carsten Bormann , "Lars Schmertmann" >=20 >=20 > A new version of I-D, draft-schmertmann-dice-codtls-00.txt > has been successfully submitted by Carsten Bormann and posted to the > IETF repository. >=20 > Name: draft-schmertmann-dice-codtls > Revision: 00 > Title: CoDTLS: DTLS handshakes over CoAP > Document date: 2014-02-14 > Group: Individual Submission > Pages: 11 > URL: = http://www.ietf.org/internet-drafts/draft-schmertmann-dice-codtls-00.txt > Status: = https://datatracker.ietf.org/doc/draft-schmertmann-dice-codtls/ > Htmlized: = http://tools.ietf.org/html/draft-schmertmann-dice-codtls-00 >=20 >=20 > Abstract: > The Datagram Transport Layer Security protocol, DTLS, is usually > transported over UDP. In Constrained Node Networks, there may be > considerable limitations on the packet delivery rates and on > practically usable packet sizes. Applications often can control the > size and retransmission requirements of their data packets, but the > DTLS handshake is out of scope for such application optimizations. >=20 > This specification defines how to perform a DTLS handshake on top of > the CoAP protocol. The resulting DTLS connection may then be used > for instance for transporting CoAP, or as a source of keying > material. The latter case is particularly interesting if the CoAP > exchanges transporting the DTLS handshake messages traverse CoAP > proxies. From nobody Fri Feb 14 20:25: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 056F11A000F for ; Fri, 14 Feb 2014 20:25:43 -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 J_Oa9_gvo9X1 for ; Fri, 14 Feb 2014 20:25:39 -0800 (PST) Received: from service88.mimecast.com (service88.mimecast.com [195.130.217.12]) by ietfa.amsl.com (Postfix) with ESMTP id CEDBC1A0005 for ; Fri, 14 Feb 2014 20:25:38 -0800 (PST) Received: from usa-sjc-gw2.usa.Arm.com (fw-tnat.snv.arm.com [217.140.100.22]) (Using TLS) by service88.mimecast.com; Sat, 15 Feb 2014 04:25:35 +0000 Received: from Spock.usa.Arm.com ([fe80::6066:a427:fcf0:1568]) by usa-sjc-gw2.usa.Arm.com ([::1]) with mapi; Fri, 14 Feb 2014 20:25:33 -0800 From: Zach Shelby To: "Kumar, Sandeep" Date: Fri, 14 Feb 2014 20:25:30 -0800 Thread-Topic: [Dtls-iot] New Version Notification for draft-keoh-dice-multicast-security-05.txt Thread-Index: Ac8qBfcKphqYw8LLQIqd5QU9Ka3NEw== Message-ID: References: <20140214160858.5956.3525.idtracker@ietfa.amsl.com> 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: 114021504253502102 Content-Type: text/plain; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/60r_1ZSTIzre4CBMsUkKI25yTco Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] New Version Notification for draft-keoh-dice-multicast-security-05.txt 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: Sat, 15 Feb 2014 04:25:43 -0000 Thanks for updating the draft with more of Mike's recommendations. This dra= ft is in line with the security problem that we were chartered to solve, an= d it purposely excludes key management. The draft focuses on a shared group= key approach, and it does seem that people involved actually deploying con= strained devices feel comfortable with the limitations pointed out (at leas= t for their use cases). Mike, is there anything else the authors can do to = clarify or narrow down the scope within this shared key approach? Some of what Mike was asking for here is obviously out of scope, for exampl= e a key management scheme, or a DTLS multicast solution applicable outside = of IoT. If we do want to solve a more general multicast security problem fo= r the Internet as a whole, that should probably done in SAAG, not DICE. How= ever he does make a valid point regarding asymmetric keys that we as a WG n= eed to explore before going forward. Several people have pointed out that asymmetric crypto with ECC is by no me= ans an issue for most embedded devices today (I happen to agree). The trend= is that asymmetric crypto will eventually be universally available, so we = really can't ignore it. Some questions I think we need to answer: - What would a DTLS record layer multicast solution employing asymmetric ke= ys look like for IoT? - Can this be done using the current DTLS record layer (which we are charte= red to use)? - Does such a solution require an unreasonable key management scheme (that = would be bad since we're not charted to define one), or could it be employe= d with simple device configuration? - Could an asymmetric key mode be supported in addition to a shared key mod= e, just like we do in TLS today? We would appreciate a separate draft, or simply an appendix to draft-keoh-d= ice-multicast-security, to document what an asymmetric key mode would look = like in practice. Thanks, Zach On Feb 14, 2014, at 8:13 AM, "Kumar, Sandeep" w= rote: > Dear all > > A new version of the draft has been submitted that takes Mike=92s comment= s into consideration especially the group sizes. > > It is good to clarify that the solution described is not a generic soluti= on to solve every multicast security problem in IoT or the Internet. We hav= e a very specific problem domain of some group members being distributed in= multiple mesh (with L2 security) which are connected through the backbone.= If they were located in a single physical subnet, then L2 security would h= ave sufficed. The intention is to provide the same level of L2 security to= this distributed group. Any source authenticity solutions are complementar= y and can be additionally designed at the application layer. > > Kind regards > Sandeep > > ---- > Changes from keoh-04 to keoh-05: > > o In section 2.1, removed the firmware upgrade use case and clarified > the commissioning use case. The lighting use-case expanded with > shared and multiple subnets issues. > > o In Section 2.2, (b) reduced the group size to 100; (h) clarified > data source authenticity > > o Added new Section 6.1 (Group level security) in security > considerations to make clear the risks of the single group key. > > > -----Original Message----- > From: internet-drafts@ietf.org [mailto:internet-drafts@ietf.org] > Sent: Friday, February 14, 2014 5:09 PM > To: Kumar, Sandeep; Garcia Morchon, Oscar; Kumar, Sandeep; Sye Loong Keoh= ; Dijk, Esko; Garcia Morchon, Oscar; Dijk, Esko; Akbar Rahman; Sye Loong Ke= oh; Akbar Rahman > Subject: New Version Notification for draft-keoh-dice-multicast-security-= 05.txt > > > A new version of I-D, draft-keoh-dice-multicast-security-05.txt > has been successfully submitted by Sandeep S. Kumar and posted to the IET= F repository. > > Name: draft-keoh-dice-multicast-security > Revision: 05 > Title: DTLS-based Multicast Security for Low-Power and Lossy Net= works (LLNs) > Document date: 2014-02-14 > Group: Individual Submission > Pages: 21 > URL: http://www.ietf.org/internet-drafts/draft-keoh-dice-multi= cast-security-05.txt > Status: https://datatracker.ietf.org/doc/draft-keoh-dice-multicas= t-security/ > Htmlized: http://tools.ietf.org/html/draft-keoh-dice-multicast-secu= rity-05 > Diff: http://www.ietf.org/rfcdiff?url2=3Ddraft-keoh-dice-multic= ast-security-05 > > Abstract: > The CoAP and 6LoWPAN standards are fast emerging as key protocols in > the area of resource-constrained devices. Such IP-based systems are > foreseen to be used for building and lighting control systems where > wireless devices interconnect with each other, forming low-power and > lossy networks (LLNs). Both multicast and its security are key needs > in these networks. This draft presents a method for securing IPv6 > multicast communication in LLNs based on the DTLS which is already > supported for unicast communication for CoAP devices. This draft > deals with the adaptation of the DTLS record layer to protect > multicast group communication, assuming that all group members > already have the group security association parameters in their > possession. The adapted DTLS record layer provides message > confidentiality, integrity and replay protection to group messages > using the group keying material before sending the message via IPv6 > multicast to the group. > > > > > Please note that it may take a couple of minutes from the time of submiss= ion until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > ________________________________ > The information contained in this message may be confidential and legally= protected under applicable law. The message is intended solely for the add= ressee(s). If you are not the intended recipient, you are hereby notified t= hat any use, forwarding, dissemination, or reproduction of this message is = strictly prohibited and may be unlawful. If you are not the intended recipi= ent, please contact the sender by return e-mail and destroy all copies of t= he original message. > _______________________________________________ > 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 Sun Feb 16 05:23:36 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 598F31A01F6 for ; Sun, 16 Feb 2014 05:23:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, 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 n9qo48D_qNHl for ; Sun, 16 Feb 2014 05:23:32 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by ietfa.amsl.com (Postfix) with ESMTP id CDAFC1A03EC for ; Sun, 16 Feb 2014 05:23:31 -0800 (PST) Received: from [192.168.10.232] ([80.43.126.29]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MDhny-1WW18T3CPO-00H5He for ; Sun, 16 Feb 2014 14:23:28 +0100 Message-ID: <5300BBCD.4000809@gmx.net> Date: Sun, 16 Feb 2014 13:23:25 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.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="pMPNmeh6WfJicLqXU5mjuJwuN74pM9VuR" X-Provags-ID: V03:K0:0MQI2+wZDBwNjo2GzOBxWxYejFN7i3FOx3AfcIde3AzLqHfgVmI NIYP5H+AeQJ5acQg2t0c995b8PnKuFRKeMrsXBmozLcnbYOWUqBQ/f7WVHaUPlrEg6bSBnm EcKJD9lMPBjeFbqwwb9LLTtvYrbcIpQ9MdVQPO/x2/UCP5j5kqZ8abKdg9l9GNjLKkynB1K zxNeJjhATJonknYCRzseA== Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/gY0p3DB_FwXgCXnn7g3236c6Q5s Subject: [Dtls-iot] 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: Sun, 16 Feb 2014 13:23:34 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --pMPNmeh6WfJicLqXU5mjuJwuN74pM9VuR Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi all, on Friday I submitted an updated version of draft-hartke-dice-profile, the DTLS 1.2 profile for IoT. Version 02 of the document only contained an table of contents and the updated version now includes content within the sections. Given the large number of changes to the document I believe it would be beneficial to get some agenda time at the upcoming meeting. I would like to go through the recommendations in the document to solicit feedback from the group. The following questions appear interesting to me: 1) Is the communication model described in Section 2 a good starting point? Are there other communication models the group would like to see discussed? While the focus on unicast communication is likely not to be controversial (since there is a separate document in the charter of the group focused on multicast security with DTLS) there are still many other communication models to focus on even for unicast. 2) Are the recommendations regarding the PSK ciphersuite sound? 3) Are the recommendations for the use of raw public keys appropriate? 4) Are the recommendations for certificate use useful? 5) Section 7 discusses error handling and gives recommendations regarding various error codes. Is this level of detail useful for you? 6) Currently Section 8 recommends session resumption to be implemented and used. The downside of it is the additional RAM and code requirements. On the plus side the improved crypto performance, energy consumption, and lower bandwidth requirement. 7) The document recommends not to use compression at the TLS layer. Is this OK? 8) Section 10 briefly talks about PFS and notes that the PSK ciphersuite does not offer PFS. The downside of PFS is the cost of generating and using Diffie-Hellman crypto. The plus is that is offers additional security features, namely forward secrecy. 9) Section 11 points to the keep-alive extension and ask the question whether it should be used or not. Do people have experience with it? 10) Regarding downgrading attacks this profile argues that I-D.bmoeller-tls-downgrade-scsv does not need to be used. To mitigate the TLS renegotiation attack [RFC5746] the recommendation is made to not use renegotiation at all. 11) Privacy: I have added a discussion about privacy to the document. Some of you might have other suggestions on how to structure the text or other concerns. Smaller issues are: a) How important is the alignment with recommendations given in I-D.sheffer-tls-bcp? (raised in Section 5) b) Should we provide some indication about the level of the certificate hierarchy? (raised in Section 6) c) How much should we focus on CoAP vs. non-CoAP based protocols for use with this DTLS profile? There is also text missing from the draft, namely a discussion about what extension from RFC 6066 to re-use. My current thinking is that we should support the following two extensions: * Client Certificate URLs: With the TLS cached info extension the client can cache server certificate chains but in order to avoid sending the client certificate + chain the certificate URL is ideally suited leading to a significant reduction in message size. * Trusted CA Indication: This allows the client to indicate what trust anchor it has and therefore allows the server to make more informed decisions about what to return to the client. Since the client will only have a few trust anchors the size of data that is sent to the server is small. I think that the Truncated MAC extension is an extension useful to reduce the size of the MAC included in the Record Layer. However, if we use more modern ciphersuites based on the AEAD design then they already offer shorter authentication tags anyway. Hence, I believe we don't need this extension. For the Server Name Indication and the Maximum Fragment Length Negotiation extensions I am not sure. Comments are welcome. Ciao Hannes --pMPNmeh6WfJicLqXU5mjuJwuN74pM9VuR 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/ iQEcBAEBCgAGBQJTALvNAAoJEGhJURNOOiAt0GkH/0slPbMv5SRGEOstJb86hIVb BwfXmQ5qLT6b17HepIGgj5uoco65T98VMi2/OMItOMwKmkywwzKFb+CIYPPP2B4O j7JETys8T5BD8mmc0fHHTAtOSExBIe1Mn+dB0XpZQLGtoIDN175a/YrhqcLGaL8c FV2jVnsSRk7+gsC3VPGWj7EmgOSFlaIxrckSBgxteILrH9eiG7qQlPSSuZzP+1uS 959ghbweyNGpRAWvZRJIkgBHrEoDoqjTrhdHnJDiamI4yf1ElzfgUkbjmZS1/08e eN9AYgr51tWHb92MRgK3sqcc3Pu0l2k+BrVTUVzqpQLaVg33jXM59cBqYW8BPy8= =hs8E -----END PGP SIGNATURE----- --pMPNmeh6WfJicLqXU5mjuJwuN74pM9VuR-- From nobody Sun Feb 16 11:24:06 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 ED8111A025C for ; Sun, 16 Feb 2014 11:24:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, 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 zwv4U1IiSe1w for ; Sun, 16 Feb 2014 11:24:02 -0800 (PST) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) by ietfa.amsl.com (Postfix) with ESMTP id E4C991A0255 for ; Sun, 16 Feb 2014 11:24:01 -0800 (PST) Received: from [192.168.10.233] ([80.43.126.29]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0MCtNr-1WOEGr1Gzb-009gpF for ; Sun, 16 Feb 2014 20:23:58 +0100 Message-ID: <5301104B.5060706@gmx.net> Date: Sun, 16 Feb 2014 19:23:55 +0000 From: Hannes Tschofenig User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.2.0 MIME-Version: 1.0 To: Daniel Migault , Sye Loong Keoh References: In-Reply-To: X-Enigmail-Version: 1.5.2 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="Kul6mWjcqa77HiVvu7FM7m68xF3v7pCg2" X-Provags-ID: V03:K0:xjGXcKMDrMscWB5reVrALOV8uZ2gcpw24QyoDP4FuLen66bicD9 ta014AdU5yAAkAkKvomzd3jrRhefTVZKCnwlG6jClqX114WD4FkirQG8XnfDOTS660xiwYt Pyg0GT5tcpT0CF9RAQczFiqovzy/009scjZfxjo3XqW7KiYzeGyZnHKaNSFj/vQd2wohurk tFhO6pXK6IzQyn9yIKK/A== Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/8dcUcgKfuWxAJW2o6FRDPqH4pMM Cc: lwip@ietf.org, "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP 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, 16 Feb 2014 19:24:05 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kul6mWjcqa77HiVvu7FM7m68xF3v7pCg2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Daniel, thanks for the pointer to the ipsecme agenda. I agree with you that ipsecme would be the right place to get this work done since the proposal makes changes to IPsec ESP and they have the needed experience. LWIG, as part of the charter, is not allowed to make changes to existing protocols, as this snippet from the charter illustrates: " The group shall also not develop any new protocols or protocol behavior modifications beyond what is already allowed by existing RFCs, because it is important to ensure that different types of devices can work togeth= er. " Ciao Hannes On 02/13/2014 02:45 PM, Daniel Migault wrote: > Hi, >=20 > We have not updated the draft to change their names, but I agree they > definitely better fit in the LWIG. We would like to present them both > in LWIG in London. >=20 > Note Tero has been provided a 20 minute slot for an overview on "IPsec > in constrained environments". So people interested in IoT and security > should check the agenda at ipsecme too. >=20 > [1] http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme >=20 > On Tue, Feb 4, 2014 at 2:53 AM, Sye Loong Keoh > wrote: >> Hi Daniel, >> >> As pointed out by Hannes, DICE WG is not chartered to look at IPSec fo= r IoT. >> However, I think your draft might be useful for LWIG WG though. >> >> Cheers >> Sye Loong >> >> -----Original Message----- >> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Daniel = Migault >> Sent: Friday, 31 January, 2014 10:48 PM >> To: ipsec@ietf.org; dtls-iot@ietf.org >> Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP >> >> Hi, >> >> Please find the two drafts we have just posted. They are about IPsec/E= SP minimal implementation and Diet-ESP designed for IoT. >> >> Comment are welcome! >> >> Best Regards, >> Daniel >> >> >> Name: draft-mglt-dice-diet-esp >> Revision: 00 >> Title: Diet-ESP: a flexible and compressed format for IPsec/ESP= >> Document date: 2014-01-31 >> Group: Individual Submission >> Pages: 21 >> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.tx= t >> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/ >> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00 >> >> >> Abstract: >> IPsec/ESP has been designed to secure IP packets exchanged between >> two nodes. IPsec implements security at the IP layer which makes >> security transparent to the applications, as opposed to TLS or DTLS= >> that requires application to implement TLS/DTLS. As a result, IPse= c >> enable to define the security rules in a similar way one establishe= s >> firewall rules. >> >> One of the IPsec's drawbacks is that implementing security on a per= >> packet basis adds overhead to each IP packet. Considering IoT >> devices, the data transmitted over an IP packet is expected to be >> rather small, and the cost of sending extra bytes is so high that >> IPsec/ESP can hardly be used for IoT as it is currently defined in >> RFC 4303. >> >> This document defines Diet-ESP, a protocol that compress and reduce= >> the ESP overhead of IPsec/ESP so that it can fit security and energ= y >> efficient IoT requirements. Diet-ESP use already existing mechanis= m >> like IKEv2 to negotiate the compression format. Furthermore a lot = of >> information, already existing for an IPsec Security Association, ar= e >> reused to offer light negotiation in addition to maximum compressio= n. >> >> >> Name: draft-mglt-lwig-minimal-esp >> Revision: 00 >> Title: Minimal ESP >> Document date: 2014-01-31 >> Group: Individual Submission >> Pages: 6 >> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00= =2Etxt >> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ >> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00 >> >> >> Abstract: >> This document describes a minimal version of the IP Encapsulation >> Security Payload (ESP) described in RFC 4303 which is part of the >> IPsec suite. >> >> ESP is used to provide confidentiality, data origin authentication,= >> connectionless integrity, an anti-replay service (a form of partial= >> sequence integrity), and limited traffic flow confidentiality. >> >> This document does not update or modify RFC 4303, but provides a >> compact description of the minimal version of the protocol. If thi= s >> document and RFC 4303 conflicts then RFC 4303 is the authoritative >> description. >> >> >> -- >> Daniel Migault >> Orange Labs -- Security >> +33 6 70 72 69 58 >> _______________________________________________ >> dtls-iot mailing list >> dtls-iot@ietf.org >> https://www.ietf.org/mailman/listinfo/dtls-iot >=20 >=20 >=20 --Kul6mWjcqa77HiVvu7FM7m68xF3v7pCg2 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/ iQEcBAEBCgAGBQJTARBLAAoJEGhJURNOOiAtxDcH/044RUTbzYrCq0MnyMDdeOh4 o4n7qBCa9nFqNfO7QGs7HKkiKCP+V9Vf2S5twIg2MtUa0jCisilcRQrA+Fb+p2ly NMGb6ndrlzwgWYwRghCYGq5UK8qcMDd6xB+JiZy4SZnw7s+UXAXJLLxr2vL+bIjw 8HArqbbB3vicZ9Cez8le3Be4NHJjrOW0x13HGz/6jpgBE4o28vyLJpNKRj1hvy7L TXC026NeAmaMNDwF6Xotof9X8jJDfQ1P3oi3FLMC3ACXeVbIQcbUwDV4jNOKiRhq Dnzy38nw07diiPgZ8Y9zVOI3FpfRyw90dQSmzbCJpZYnbhrlKJeddhLHsYkBVa0= =qgNA -----END PGP SIGNATURE----- --Kul6mWjcqa77HiVvu7FM7m68xF3v7pCg2-- From nobody Sun Feb 16 19:57: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 DB34D1A0332 for ; Sun, 16 Feb 2014 19:57:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5d9twaBFQ4OU for ; Sun, 16 Feb 2014 19:57:27 -0800 (PST) Received: from mail-qa0-f46.google.com (mail-qa0-f46.google.com [209.85.216.46]) by ietfa.amsl.com (Postfix) with ESMTP id 48F611A0031 for ; Sun, 16 Feb 2014 19:57:27 -0800 (PST) Received: by mail-qa0-f46.google.com with SMTP id k15so7872103qaq.33 for ; Sun, 16 Feb 2014 19:57:24 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=drr9OjRzM1f5UgoiY43lhGmcimNTW2eSYBC2laoHSKk=; b=aV5CH+AarLdN6GDlSIwJYNQtyEjhlNVMosD+mzGE9l/WZ0nyfJdukLAntUWn8CM0qc VHL5jw3prXy7g7Z0SkbGvUnr0Bs0rENHSC2Iammjav8aOIrV4gU+uAKUMI0E+YATJ2g1 5/PfO0U4uPJ1SpLLcv/9J8H0rFyKkPSSqdx2p8qZwv17dc6OMpxEP+0Ug8x4A8C136+I oQRbyxy/+Duwkgjny28rCFokwpBv6/Nmxf7Q/jlHMicorvasCxxTB02wPn2bv/ZZ+mHZ sqlEYVD6nNWAjytYErIwKotn7I9U/tLchTCHrLH4kEX6syU2K0jJxaO/VCYJhO/h4vd2 r/Bg== X-Gm-Message-State: ALoCoQlFfThf+/2TBBHOIaJx/gKm6N9QpEvewCKJfb7YLrpMlmalF937yQwHNsGnINpLwkr/8LhF X-Received: by 10.224.5.136 with SMTP id 8mr32309841qav.42.1392609444756; Sun, 16 Feb 2014 19:57:24 -0800 (PST) Received: from [192.168.1.105] (c-68-34-113-195.hsd1.md.comcast.net. [68.34.113.195]) by mx.google.com with ESMTPSA id g68sm20305534qge.7.2014.02.16.19.57.24 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 16 Feb 2014 19:57:24 -0800 (PST) Message-ID: <530188A3.7010002@nthpermutation.com> Date: Sun, 16 Feb 2014 22:57:23 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: dtls-iot@ietf.org References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/aCrLWajakeC_w8N1cuDbTiQH9DY Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy 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 Feb 2014 03:57:29 -0000 On 2/14/2014 10:24 AM, Carsten Bormann wrote: > There is also a more radical proposal in the document: in AES-CCM, SHA-256 is only used in the PRF, and for this kind of application, it would be nice to be able to save those 2 KiB or so. So we define a CMAC-based PRF as a potential alternative. Of course, we don’t even play cryptographers on TV, so this part is just a strawman that would need some significant scrutiny. Again, DICE might be a forum to consider whether this is worth pursuing. Cryptographically, there's really no problem with using CMAC as a PRF (and in fact there is a definition of a KDF that does exactly that in SP800-108 as you note). The constraining issue is that CMAC doesn't have a defined compression/expansion function defined for a provided key. The CMAC key is expected to be the native key length of the underlying block cipher (e.g. 128, 192 or 256 bits for AES). This differs from HMAC as HMAC defines a mechanism for taking in any length of key bytes and either compressing (by hashing the key bytes) or expanding (by padding with zero) to the length of the underlying hash's block size. Given that the pre-master secret for TLS could notionally be any length and the master secret is always 48 bytes in length, we'd need to define how to impedance match to the CMAC key length. Mike From nobody Mon Feb 17 00:57: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 0E1EE1A00BF for ; Mon, 17 Feb 2014 00:57:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NERdBZnzkPSG for ; Mon, 17 Feb 2014 00:57:49 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id 5A0EC1A00B6 for ; Mon, 17 Feb 2014 00:57:49 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1H8vd8e007276; Mon, 17 Feb 2014 09:57:39 +0100 (CET) Received: from [192.168.217.105] (p54893775.dip0.t-ipconnect.de [84.137.55.117]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6D5469E9; Mon, 17 Feb 2014 09:57:33 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: <530188A3.7010002@nthpermutation.com> Date: Mon, 17 Feb 2014 09:57:31 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <79A752A1-F1A1-4645-8920-A4D3BF7722AA@tzi.org> References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> <530188A3.7010002@nthpermutation.com> To: Michael StJohns X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/CDETsjKQsh5-LpgnflX7vstdC6c Cc: dtls-iot@ietf.org Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy 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 Feb 2014 08:57:51 -0000 On 17 Feb 2014, at 04:57, Michael StJohns = wrote: > Given that the pre-master secret for TLS could notionally be any = length and the master secret is always 48 bytes in length, we'd need to = define how to impedance match to the CMAC key length. Yes. We stole the idea from RFC 4615 (compress the PRF key by MACing it = with all-zeroes AES key) and modified it slightly to get more entropy = out of the key (use a counter instead of all-zeroes). RFC 4615 is from = 2006, is there more experience with this approach now? Gr=FC=DFe, Carsten From nobody Tue Feb 18 05:06:24 2014 Return-Path: X-Original-To: dtls-iot@ietfa.amsl.com Delivered-To: dtls-iot@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9006B1A04BE; Tue, 18 Feb 2014 05:06:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 HxcqeIkjg2oJ; Tue, 18 Feb 2014 05:06:18 -0800 (PST) Received: from mail-we0-x22d.google.com (mail-we0-x22d.google.com [IPv6:2a00:1450:400c:c03::22d]) by ietfa.amsl.com (Postfix) with ESMTP id 6459C1A03E4; Tue, 18 Feb 2014 05:06:17 -0800 (PST) Received: by mail-we0-f173.google.com with SMTP id x48so5906333wes.18 for ; Tue, 18 Feb 2014 05:06:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:date:message-id:subject:from:to:cc:content-type; bh=ytU74mhsAvmOXMMSOl6vQfnoNAP65lbwxhL77WmICm8=; b=KGujQ7OL1nOKvx7BXVNwtnH8rn7UHnP2ItjZoCu8nU6dmJ3EiUCkC0sIxpNDEOPvvQ 0rE40h3gVOg9LNWmSy1ol+J3Uqq/oQEb4XF+SBwb9ypy7X8GBAaUdAed8rrsbbq0A3GB ydLD7s3b5ECg0HOAwK6UyJ9Nytn3+tHzxI03OpqnXcGHKCEPmwpy+khPXIvoHREge6xf LL4gcooyLplTxWZMUExOogDh4zhb5n2Ebo1cDRxzfNVvWCYEX0OS0Wtd5pir6dRCEhew EoaUNW2i95vbNbOSCKCzUOqUEd79bTUApccTcPfi8UvuWyRzbXD7P8goEMLsnEutS2Y5 kRfA== MIME-Version: 1.0 X-Received: by 10.180.24.227 with SMTP id x3mr18078312wif.41.1392728773999; Tue, 18 Feb 2014 05:06:13 -0800 (PST) Received: by 10.194.171.129 with HTTP; Tue, 18 Feb 2014 05:06:13 -0800 (PST) Date: Tue, 18 Feb 2014 14:06:13 +0100 Message-ID: From: Daniel Migault To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/rtik_JS2muMJKYcmrIdANpIP2Fg Cc: "ipsec@ietf.org" , lwip@ietf.org, "dtls-iot@ietf.org" , Sye Loong Keoh Subject: Re: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP 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, 18 Feb 2014 13:06:21 -0000 Hi Hannes, Thank you for pointing out the issue. Actually we wanted to have feed back from both communities. - lwig for IoT to make sure we address all or relevant scenarios of IoT, and understand those we do not address. - ipsecme for the design of diet-esp. My understanding is that diet-esp should then be more an ipsecme draft and minimal esp should be in lwig. We will make this change in the next version of the draft diet-esp this week! Now comes also another question: Is diet-ESP a new protocol, a new extension, a ESP compression algorithm.... I would be happy to get opinion on that. 1) Diet-ESP: Extension vs Protocol - a) Diet-ESP is an IPsec extension The way we considered to peers agreeing on the diet-esp context is using minimal IKE sending an DIET-ESP_SUPPORTED Notify Payloads with proposition of DIET-ESP Context. The responder just ignores the propositions or chose one. All remaining stuff would be negotiated via the traditional CREATE_CHILD_SA were peers would agree on ESP, keys, algos.... >From that point of view it looks the diet-ESP is more a wire-compression algorithm. If not supported by one of the peer we fall back with standard ESP. -b) Diet-ESP is a new Protocol Another way would be to consider that all parameters of the Diet-ESP Context would be negotiated in the CREATE_CHILD_SA exchange with new Transform structures. >From that point of view diet-esp would look more like a new protocol and the possible choice may be IKE/ESP/AH/DIET-ESP.... There might be other alternatives I would be happy to hear about. For now I like better the extension way. 2) What Diet-ESP changes from regular ESP Diet-ESP changes IPsec and ESP headers, trailers with smaller fields. Diet-ESP changes the way the packet is compressed and encrypted. On the other hand, for a sensor with a single diet-ESP configuration, most of the IPsec stack remains unchanged. This is not so true for peers that are able to handle all Diet-ESP configuraions. In that case the standard way of looking up in the SAD may be changed. We will provide a better description of this in the next version of the draft. BR, Daniel On Sun, Feb 16, 2014 at 8:23 PM, Hannes Tschofenig wrote: > Hi Daniel, > > thanks for the pointer to the ipsecme agenda. > > I agree with you that ipsecme would be the right place to get this work > done since the proposal makes changes to IPsec ESP and they have the > needed experience. > > LWIG, as part of the charter, is not allowed to make changes to existing > protocols, as this snippet from the charter illustrates: > " > The group shall also not develop any new protocols or protocol behavior > modifications beyond what is already allowed by existing RFCs, because > it is important to ensure that different types of devices can work together. > " > > > Ciao > Hannes > > On 02/13/2014 02:45 PM, Daniel Migault wrote: >> Hi, >> >> We have not updated the draft to change their names, but I agree they >> definitely better fit in the LWIG. We would like to present them both >> in LWIG in London. >> >> Note Tero has been provided a 20 minute slot for an overview on "IPsec >> in constrained environments". So people interested in IoT and security >> should check the agenda at ipsecme too. >> >> [1] http://www.ietf.org/proceedings/89/agenda/agenda-89-ipsecme >> >> On Tue, Feb 4, 2014 at 2:53 AM, Sye Loong Keoh >> wrote: >>> Hi Daniel, >>> >>> As pointed out by Hannes, DICE WG is not chartered to look at IPSec for IoT. >>> However, I think your draft might be useful for LWIG WG though. >>> >>> Cheers >>> Sye Loong >>> >>> -----Original Message----- >>> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Daniel Migault >>> Sent: Friday, 31 January, 2014 10:48 PM >>> To: ipsec@ietf.org; dtls-iot@ietf.org >>> Subject: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP >>> >>> Hi, >>> >>> Please find the two drafts we have just posted. They are about IPsec/ESP minimal implementation and Diet-ESP designed for IoT. >>> >>> Comment are welcome! >>> >>> Best Regards, >>> Daniel >>> >>> >>> Name: draft-mglt-dice-diet-esp >>> Revision: 00 >>> Title: Diet-ESP: a flexible and compressed format for IPsec/ESP >>> Document date: 2014-01-31 >>> Group: Individual Submission >>> Pages: 21 >>> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt >>> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/ >>> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00 >>> >>> >>> Abstract: >>> IPsec/ESP has been designed to secure IP packets exchanged between >>> two nodes. IPsec implements security at the IP layer which makes >>> security transparent to the applications, as opposed to TLS or DTLS >>> that requires application to implement TLS/DTLS. As a result, IPsec >>> enable to define the security rules in a similar way one establishes >>> firewall rules. >>> >>> One of the IPsec's drawbacks is that implementing security on a per >>> packet basis adds overhead to each IP packet. Considering IoT >>> devices, the data transmitted over an IP packet is expected to be >>> rather small, and the cost of sending extra bytes is so high that >>> IPsec/ESP can hardly be used for IoT as it is currently defined in >>> RFC 4303. >>> >>> This document defines Diet-ESP, a protocol that compress and reduce >>> the ESP overhead of IPsec/ESP so that it can fit security and energy >>> efficient IoT requirements. Diet-ESP use already existing mechanism >>> like IKEv2 to negotiate the compression format. Furthermore a lot of >>> information, already existing for an IPsec Security Association, are >>> reused to offer light negotiation in addition to maximum compression. >>> >>> >>> Name: draft-mglt-lwig-minimal-esp >>> Revision: 00 >>> Title: Minimal ESP >>> Document date: 2014-01-31 >>> Group: Individual Submission >>> Pages: 6 >>> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt >>> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ >>> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00 >>> >>> >>> Abstract: >>> This document describes a minimal version of the IP Encapsulation >>> Security Payload (ESP) described in RFC 4303 which is part of the >>> IPsec suite. >>> >>> ESP is used to provide confidentiality, data origin authentication, >>> connectionless integrity, an anti-replay service (a form of partial >>> sequence integrity), and limited traffic flow confidentiality. >>> >>> This document does not update or modify RFC 4303, but provides a >>> compact description of the minimal version of the protocol. If this >>> document and RFC 4303 conflicts then RFC 4303 is the authoritative >>> description. >>> >>> >>> -- >>> Daniel Migault >>> Orange Labs -- Security >>> +33 6 70 72 69 58 >>> _______________________________________________ >>> dtls-iot mailing list >>> dtls-iot@ietf.org >>> https://www.ietf.org/mailman/listinfo/dtls-iot >> >> >> > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Tue Feb 18 05:22: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 A4B721A04BF; Tue, 18 Feb 2014 05:22:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 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, 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 ExKevo7n0Lvx; Tue, 18 Feb 2014 05:22:28 -0800 (PST) Received: from mail-we0-x22a.google.com (mail-we0-x22a.google.com [IPv6:2a00:1450:400c:c03::22a]) by ietfa.amsl.com (Postfix) with ESMTP id 9023A1A04B1; Tue, 18 Feb 2014 05:22:27 -0800 (PST) Received: by mail-we0-f170.google.com with SMTP id w62so11752888wes.29 for ; Tue, 18 Feb 2014 05:22:24 -0800 (PST) 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=hYFllRPDFL37bUQZgtAXIxSTM0SS/gO+4uiG5Kfcf4Y=; b=QByA7slGg8LbsG4RiiV8OH95pVzPgOVvvv0FjL3gnCrQdJ3uGAXqgBRJ+QwsI1w76w Oo0QtXMfTotrdx9BmBuFJMoH/Q2hQvbLm/xcHwZuh7D6aahuO/qlsNW/wQ8ObLnhgQRU jjvPsHIs618LG6GMyjXZTiaeR3ZndTIfCexuWoN5YMammlc9yXN69CwcBhKZ9NNI+b+J 7UZ7lfRyv9ChJxov83ltOo3+Ib9MVqoqDWwuGCv4YZ8GswpQCfIwVeAQfZolFqL4gs2w GYPPnYsjFasn1YkyK+4QN485iUTnEvPzm44mleEX0e33M9uISGGMQ1CTPjqsz0FmAjKa 2OYQ== MIME-Version: 1.0 X-Received: by 10.194.87.5 with SMTP id t5mr1912317wjz.68.1392729744184; Tue, 18 Feb 2014 05:22:24 -0800 (PST) Received: by 10.194.171.129 with HTTP; Tue, 18 Feb 2014 05:22:24 -0800 (PST) In-Reply-To: <52EC03BC.60609@gmx.net> References: <52EC03BC.60609@gmx.net> Date: Tue, 18 Feb 2014 14:22:24 +0100 Message-ID: From: Daniel Migault To: Hannes Tschofenig Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/fUHLUv2is9GGvsuyk9el02zqrLk Cc: "ipsec@ietf.org" , tobias.guggemos@stud.ifi.lmu.de, "dtls-iot@ietf.org" , dominique.barthel@orange.com Subject: Re: [Dtls-iot] IPsec/Diet-ESP for IoT and Minimal ESP 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, 18 Feb 2014 13:22:30 -0000 Hi Hannes, So yes I agree, minimal ESP better fits lwig whereas diet-esp better fits ipsecme. Orange already operates networks of smart communicating objects, either directly or through its joint-venture m2o City. Orange is committed to contributing to the advent of the Internet of Things. Dominique is maybe the best entry point to know more on our activities with IoT. We are currently looking at using IPsec and compare it with TLS as a research topic. Currently Tobi implemented Diet-ESP on Python and for contiki. As soon as we have published tests we will provide the code as opensource. BR, Daniel On Fri, Jan 31, 2014 at 9:12 PM, Hannes Tschofenig wrote: > Hi Daniel, > > the charter of the DICE working group considers IPsec/IKEv2 outside the > scope. The charter also requires the work to be a profile rather than a > new design. A profile is just a subset of the functionality of the > existing protocol that would still interoperate with the full version. > > On the content: Do you plan to use the work within your company / in > products? I have not ran into someone who was planning to use IPsec in > the IoT context but I am happy to learn about new deployments. > > Ciao > Hannes > > > On 01/31/2014 02:48 PM, Daniel Migault wrote: >> Hi, >> >> Please find the two drafts we have just posted. They are about >> IPsec/ESP minimal implementation and Diet-ESP designed for IoT. >> >> Comment are welcome! >> >> Best Regards, >> Daniel >> >> >> Name: draft-mglt-dice-diet-esp >> Revision: 00 >> Title: Diet-ESP: a flexible and compressed format for IPsec/ESP >> Document date: 2014-01-31 >> Group: Individual Submission >> Pages: 21 >> URL:http://www.ietf.org/internet-drafts/draft-mglt-dice-diet-esp-00.txt >> Status:https://datatracker.ietf.org/doc/draft-mglt-dice-diet-esp/ >> Htmlized:http://tools.ietf.org/html/draft-mglt-dice-diet-esp-00 >> >> >> Abstract: >> IPsec/ESP has been designed to secure IP packets exchanged between >> two nodes. IPsec implements security at the IP layer which makes >> security transparent to the applications, as opposed to TLS or DTLS >> that requires application to implement TLS/DTLS. As a result, IPsec >> enable to define the security rules in a similar way one establishes >> firewall rules. >> >> One of the IPsec's drawbacks is that implementing security on a per >> packet basis adds overhead to each IP packet. Considering IoT >> devices, the data transmitted over an IP packet is expected to be >> rather small, and the cost of sending extra bytes is so high that >> IPsec/ESP can hardly be used for IoT as it is currently defined in >> RFC 4303. >> >> This document defines Diet-ESP, a protocol that compress and reduce >> the ESP overhead of IPsec/ESP so that it can fit security and energy >> efficient IoT requirements. Diet-ESP use already existing mechanism >> like IKEv2 to negotiate the compression format. Furthermore a lot of >> information, already existing for an IPsec Security Association, are >> reused to offer light negotiation in addition to maximum compression. >> >> >> Name: draft-mglt-lwig-minimal-esp >> Revision: 00 >> Title: Minimal ESP >> Document date: 2014-01-31 >> Group: Individual Submission >> Pages: 6 >> URL:http://www.ietf.org/internet-drafts/draft-mglt-lwig-minimal-esp-00.txt >> Status:https://datatracker.ietf.org/doc/draft-mglt-lwig-minimal-esp/ >> Htmlized:http://tools.ietf.org/html/draft-mglt-lwig-minimal-esp-00 >> >> >> Abstract: >> This document describes a minimal version of the IP Encapsulation >> Security Payload (ESP) described in RFC 4303 which is part of the >> IPsec suite. >> >> ESP is used to provide confidentiality, data origin authentication, >> connectionless integrity, an anti-replay service (a form of partial >> sequence integrity), and limited traffic flow confidentiality. >> >> This document does not update or modify RFC 4303, but provides a >> compact description of the minimal version of the protocol. If this >> document and RFC 4303 conflicts then RFC 4303 is the authoritative >> description. >> >> > -- Daniel Migault Orange Labs -- Security +33 6 70 72 69 58 From nobody Thu Feb 20 03:56: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 9C3F11A00BA for ; Thu, 20 Feb 2014 03:56:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 QwfelW-xzeOK for ; Thu, 20 Feb 2014 03:56:50 -0800 (PST) Received: from tx2outboundpool.messaging.microsoft.com (tx2ehsobe001.messaging.microsoft.com [65.55.88.11]) by ietfa.amsl.com (Postfix) with ESMTP id E4CC01A00B6 for ; Thu, 20 Feb 2014 03:56:48 -0800 (PST) Received: from mail212-tx2-R.bigfish.com (10.9.14.249) by TX2EHSOBE008.bigfish.com (10.9.40.28) with Microsoft SMTP Server id 14.1.225.22; Thu, 20 Feb 2014 11:56:45 +0000 Received: from mail212-tx2 (localhost [127.0.0.1]) by mail212-tx2-R.bigfish.com (Postfix) with ESMTP id 1259C2C00E9; Thu, 20 Feb 2014 11:56:45 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -36 X-BigFish: VPS-36(zz98dI15d6O9371Ic89bh542Ic85dhe0eah1432I9251I217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh30d1K8275dh18c673h1de097h186068h5eeeKz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh1155h) Received: from mail212-tx2 (localhost.localdomain [127.0.0.1]) by mail212-tx2 (MessageSwitch) id 1392897401581849_5468; Thu, 20 Feb 2014 11:56:41 +0000 (UTC) Received: from TX2EHSMHS027.bigfish.com (unknown [10.9.14.226]) by mail212-tx2.bigfish.com (Postfix) with ESMTP id 7F7B21401BA; Thu, 20 Feb 2014 11:56:41 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by TX2EHSMHS027.bigfish.com (10.9.99.127) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 20 Feb 2014 11:56:37 +0000 Received: from 011-DB3MMR1-017.MGDPHG.emi.philips.com (10.128.28.102) by 011-DB3MMR1-006.MGDPHG.emi.philips.com (10.128.28.56) with Microsoft SMTP Server (TLS) id 14.3.174.2; Thu, 20 Feb 2014 11:56:35 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.12]) by 011-DB3MMR1-017.MGDPHG.emi.philips.com ([10.128.28.102]) with mapi id 14.03.0174.002; Thu, 20 Feb 2014 11:56:35 +0000 From: "Kumar, Sandeep" To: Carsten Bormann , Michael StJohns Thread-Topic: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy Thread-Index: AQHPKZjtj+qltgjdEU2o5YvDNSRTwJq41YeAgABT3ICABN+vkA== Date: Thu, 20 Feb 2014 11:56:35 +0000 Message-ID: References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> <530188A3.7010002@nthpermutation.com> <79A752A1-F1A1-4645-8920-A4D3BF7722AA@tzi.org> In-Reply-To: <79A752A1-F1A1-4645-8920-A4D3BF7722AA@tzi.org> 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: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E55EA4C011DB3MPN1025MG_" 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/ti20OVKCm3r45y6-kJk-tQYfInQ Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 11:56:53 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E55EA4C011DB3MPN1025MG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Lars, Carsten Seems like a worthwhile initiative...see comments below > -----Original Message----- > From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Carsten > Bormann > Sent: Monday, February 17, 2014 9:58 AM > To: Michael StJohns > Cc: dtls-iot@ietf.org > Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward > Secrecy > > On 17 Feb 2014, at 04:57, Michael StJohns > > wrote: > > > Given that the pre-master secret for TLS could notionally be any length= and > the master secret is always 48 bytes in length, we'd need to define how t= o > impedance match to the CMAC key length. [SK]The pre-master secret seems to be fed as the message to the CMAC, assum= ing you are using the same format T :=3D AES-CMAC(K,M,len) as in RFC4493. T= hen the size of the pre-master secret is not an issue and can be any long, = message padding is defined in CMAC. The 48 byte master-secret can be genera= ted as in TLS by the right number of iterations and discarding the last byt= es from the final iteration. With AES-CMAC there won't be any need for that= discarding. However not clear to me why TLS chose for the key expansion al= ready for the master-secret when additional key expansion is done during th= e Key Calculation phase ( rfc5246 section-6.3). > > Yes. We stole the idea from RFC 4615 (compress the PRF key by MACing it > with all-zeroes AES key) and modified it slightly to get more entropy out= of > the key (use a counter instead of all-zeroes). RFC 4615 is from 2006, is= there > more experience with this approach now? [SK] There is http://tools.ietf.org/html/rfc5869 with newer recommendation = on the KDF, however this is restricted to HMAC. The NIST SP-800-56C http://= csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf recommendation i= s based on this RFC and does include CMAC variants. Maybe good to look at t= hose recommendations too. There is an additional hash used in finished message (rfc5246 section-7.4.= 9) verify_data :=3D PRF(master_secret, finished_label, Hash(handshake_messages= )) [0..verify_data_length-1]; Removing SHA-256 would mean changing this part too. Sandeep > > Gr=FC=DFe, Carsten > > _______________________________________________ > 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. --_000_BE6D13F6A4554947952B39008B0DC0153E55EA4C011DB3MPN1025MG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Lars, Carsten

 

Seems like a worthw= hile initiative...see comments below

 

> -----Original Message-----

> From: dtls-iot [mailto:dtls-iot-bounces@ietf= .org] On Behalf Of Carsten

> Bormann

> Sent: Monday, February 17, 2014 9:58 AM

> To: Michael StJohns

> Cc: dtls-iot@ietf.org

> Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Ci= pher Suites with Forward

> Secrecy

>

> On 17 Feb 2014, at 04:57, Michael StJohns &l= t;msj@nthpermutation.com>

> wrote:

>

> > Given that the pre-master secret for TL= S could notionally be any length and

> the master secret is always 48 bytes in leng= th, we'd need to define how to

> impedance match to the CMAC key length.

 

[SK]The pre-mast= er secret seems to be fed as the message to the CMAC, assuming you are usin= g the same format T :=3D AES-CMAC(K,M,len) as in RFC4493. Then the size of = the pre-master secret is not an issue and can be any long, message padding is defined in CMAC. The 48 byte maste= r-secret can be generated as in TLS by the right number of iterations and d= iscarding the last bytes from the final iteration. With AES-CMAC there won&= #8217;t be any need for that discarding. However not clear to me why TLS chose for the key expansion already for th= e master-secret when additional key expansion is done during the Key Calcul= ation phase ( rfc5246 section-6.3).

 

>

> Yes.  We stole the idea from RFC 4615 (= compress the PRF key by MACing it

> with all-zeroes AES key) and modified it sli= ghtly to get more entropy out of

> the key (use a counter instead of all-zeroes= ).  RFC 4615 is from 2006, is there

> more experience with this approach now?

 

[SK] There is http://tools.ietf.org/html/rfc5869= with newer recommendation on the KDF, however this is restricted to HMAC. = The NIST SP-800-56C http://csrc.nist.gov/publications/nistpubs= /800-56C/SP-800-56C.pdf recommendation is based on this RFC and = does include CMAC variants. Maybe good to look at those recommendations too.

 

There is an addi= tional hash used  in finished message (rfc5246 section-7.4.9)

verify_data :=3D PRF(master_secret, finished_label, Hash(handsha= ke_messages)) [0..verify_data_length-1];

Removing SHA-256= would mean changing this part too.

 

Sandeep

 

>

> Gr=FC=DFe, Carsten

>

> ____________________________________________= ___

> dtls-iot mailing list

> dtls-iot@ietf.org=

> https://www.ietf.org/= mailman/listinfo/dtls-iot


The information contained in= this message may be confidential and legally protected under applicable la= w. The message is intended solely for the addressee(s). If you are not the = intended recipient, you are hereby notified that any use, forwarding, dissemination, or reproduction of this message i= s strictly prohibited and may be unlawful. If you are not the intended reci= pient, please contact the sender by return e-mail and destroy all copies of= the original message.
 --_000_BE6D13F6A4554947952B39008B0DC0153E55EA4C011DB3MPN1025MG_-- From nobody Thu Feb 20 04:22:46 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 C655F1A012C for ; Thu, 20 Feb 2014 04:22:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P0QwvCCCZaZH for ; Thu, 20 Feb 2014 04:22:43 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id DBFBC1A0129 for ; Thu, 20 Feb 2014 04:22:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1KCMUH8004332; Thu, 20 Feb 2014 13:22:30 +0100 (CET) Received: from [192.168.217.105] (p54891BBF.dip0.t-ipconnect.de [84.137.27.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 5B435137; Thu, 20 Feb 2014 13:22:27 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: Date: Thu, 20 Feb 2014 13:22:23 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> To: "FOSSATI, Thomas (Thomas)" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/FARU1HAqYKNAOjog4CDyhvhCTis Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 12:22:44 -0000 > an even deeper scrutiny for the =93radical=94 bit in your proposal = could come > from cfrg@irtf.org. >=20 > I think it=92d be worth dropping an email there as well. Indeed. There was a thread already four years ago, starting at: http://www.ietf.org/mail-archive/web/cfrg/current/msg02692.html In particular, Hugo Krawczyk wrote: > As for CMAC, you could use it, in principle, but you would need to be = careful about HOW to use it. In particular, how are you going to key the = cipher, what happens when you need more bits of output than those coming = out of the cipher (e.g. you want a key for AES-256 but the output is = only 128 bits), and even if your application can get all things right, = the analytical results for this construction are weaker than for HMAC. = For example, the only results we have for block ciphers as extractors = assume these ciphers are ideal random permutations (even if you can use = salt to key the cipher) while for HMAC, in many usage scenarios you do = not need to resort to ideal assumptions. (That remark is the background for the strawman in the draft.) In 2009, the thread on CFRG ended a bit inconclusive, partially because = it was mixed up with another discussion, but also because it wasn=92t = quite clear what specifically we were proposing. So I thought it would be good to come up with a DICE strawman first, = based on some consensus what it is that we are trying to achieve. Then, indeed, we should go to CFRG again if we agree this should be = done. Gr=FC=DFe, Carsten From nobody Thu Feb 20 08:43:35 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 9844F1A0225 for ; Thu, 20 Feb 2014 08:43:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.551 X-Spam-Level: X-Spam-Status: No, score=-1.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rw_tzU05mVsm for ; Thu, 20 Feb 2014 08:43:30 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C03321A022B for ; Thu, 20 Feb 2014 08:43:28 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1KGhHps022045; Thu, 20 Feb 2014 17:43:17 +0100 (CET) Received: from [192.168.217.106] (p54891BBF.dip0.t-ipconnect.de [84.137.27.191]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 329C5320; Thu, 20 Feb 2014 17:43:16 +0100 (CET) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 7.1 \(1827\)) From: Carsten Bormann In-Reply-To: Date: Thu, 20 Feb 2014 17:43:14 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4750B796-1333-4590-A3C7-102110EF2339@tzi.org> References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> <530188A3.7010002@nthpermutation.com> <79A752A1-F1A1-4645-8920-A4D3BF7722AA@tzi.org> To: "Kumar, Sandeep" X-Mailer: Apple Mail (2.1827) Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/97L8SLNeJc1s_uKNOTPQ2W-e_zU Cc: "dtls-iot@ietf.org" , Michael StJohns Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 16:43:32 -0000 On 20 Feb 2014, at 12:56, Kumar, Sandeep = wrote: > [SK]The pre-master secret seems to be fed as the message to the CMAC, = assuming you are using the same format T :=3D AES-CMAC(K,M,len) as in = RFC4493. Then the size of the pre-master secret is not an issue and can = be any long, message padding is defined in CMAC. The 48 byte = master-secret can be generated as in TLS by the right number of = iterations and discarding the last bytes from the final iteration. With = AES-CMAC there won=92t be any need for that discarding. However not = clear to me why TLS chose for the key expansion already for the = master-secret when additional key expansion is done during the Key = Calculation phase ( rfc5246 section-6.3). We tried to emulate the TLS 1.2 PRF, but aren=92t making use of any = profound insights as to its construction. Since every round of the way we are using CMAC is generating 16 bytes, = we=92ll need three rounds for the master-secret. > [SK] There is http://tools.ietf.org/html/rfc5869 with newer = recommendation on the KDF, however this is restricted to HMAC. The NIST = SP-800-56Chttp://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pd= f recommendation is based on this RFC and does include CMAC variants. = Maybe good to look at those recommendations too. RFC 4615 is essentially using the key extraction procedure defined for = CMAC in SP-800-56C. Both have in common that they are only making use = of 128 bits of entropy; there is only a single key extraction step = (which in RFC 4615, as recommended in SP-800-56C, is based on a public = salt of 0 =3D 128 bits of all zeroes). While SP-800-56C does provide = for the protocol to generate other salts, it does not provide for = parallel key extraction steps of the form our proposal uses to extract = more entropy. This construct is not validated by SP-800-56C. If we = agree that the attempt to extract more entropy is worthwhile, we=92ll = have to check with CFRG whether this or another extended extraction = procedure can be used with CMAC. But since much of the IoT world is = going to 128-bit security only, maybe that=92s not necessary in the = first place. (And thanks for pointing out section 7.4.9 of RFC 5246; we actually are = using another CMAC here in place of the hash, but the way the key is = derived for that may need to be generalized from the way we are doing = this in our implementation.) Gr=FC=DFe, Carsten From nobody Thu Feb 20 10:42:17 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 70A1E1A023E for ; Thu, 20 Feb 2014 10:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W2fgI83UAKX8 for ; Thu, 20 Feb 2014 10:42:11 -0800 (PST) Received: from mail-qc0-f173.google.com (mail-qc0-f173.google.com [209.85.216.173]) by ietfa.amsl.com (Postfix) with ESMTP id 4531B1A0235 for ; Thu, 20 Feb 2014 10:42:11 -0800 (PST) Received: by mail-qc0-f173.google.com with SMTP id i8so3781809qcq.32 for ; Thu, 20 Feb 2014 10:42:07 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:message-id:date:from:user-agent:mime-version:to :cc:subject:references:in-reply-to:content-type; bh=t8Kgl1S4j3ktaGeHuANABnHafBJw6zG4wxZ6KMAIBRA=; b=fqxRsjEp7BwQn9BletSSJrBNeRi6ZvG3OXqP4a8E2J49NWdZD6WXStBthxs3d15Rxo HXJhzy6OZkPR2PtKIUU5AbFDTFivkQBI/g4GvvTgK45u+T9QPuF6L+05PBsyqBd7L2IK dz0qzCH6qOvIhl0g7K/6wN3zbwTB+OF03IfJ0PZ25f2z1FQaruKsg/wN0swLd7GvgXRp j1RHOWumGWO50uuvmK65RAu9pBZ8pOphP3jw7qgevqxUA8H9fIHMtQANR3bI7MjhZi/s WH8XFdrKBk8bamSs+f/iZI3jG4nNcOFzUkL+3nDw+vedSsmO/E33BXrUcZZRmgzWw+E8 xdrg== X-Gm-Message-State: ALoCoQlNMcYfsd/8pbiMUnf5bX6r+ojNbtwyb6+S0FgHzSI5ZkdAG/HjwwmjaZ5xdL9HJoghrNcM X-Received: by 10.140.44.119 with SMTP id f110mr3610467qga.31.1392921727187; Thu, 20 Feb 2014 10:42:07 -0800 (PST) Received: from [10.90.129.164] (edge-gw-rwc.silverspringnet.com. [74.121.22.10]) by mx.google.com with ESMTPSA id w2sm14292017qad.19.2014.02.20.10.42.05 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 20 Feb 2014 10:42:06 -0800 (PST) Message-ID: <53064C80.6040606@nthpermutation.com> Date: Thu, 20 Feb 2014 13:42:08 -0500 From: Michael StJohns User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: "Kumar, Sandeep" , Carsten Bormann References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> <530188A3.7010002@nthpermutation.com> <79A752A1-F1A1-4645-8920-A4D3BF7722AA@tzi.org> In-Reply-To: Content-Type: multipart/alternative; boundary="------------050201010401030400020402" Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/etvnw98XbaANWtOEz0CKSmlbuGQ Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 18:42:16 -0000 This is a multi-part message in MIME format. --------------050201010401030400020402 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit On 2/20/2014 6:56 AM, Kumar, Sandeep wrote: > > Hi Lars, Carsten > > Seems like a worthwhile initiative...see comments below > > > -----Original Message----- > > > From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Carsten > > > Bormann > > > Sent: Monday, February 17, 2014 9:58 AM > > > To: Michael StJohns > > > Cc: dtls-iot@ietf.org > > > Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward > > > Secrecy > > > > > > On 17 Feb 2014, at 04:57, Michael StJohns > > > > wrote: > > > > > > > Given that the pre-master secret for TLS could notionally be any > length and > > > the master secret is always 48 bytes in length, we'd need to define > how to > > > impedance match to the CMAC key length. > > /[SK]The pre-master secret seems to be fed as the message to the CMAC, > assuming you are using the same format T := AES-CMAC(K,M,len) as in > RFC4493. Then the size of the pre-master secret is not an issue and > can be any long, message padding is defined in CMAC./ > Um... no. The K in AES-CMAC has to be the length of the underlying AES block cipher - either 128, 192, or 256 bits. RFC4493 is the same as the NIST CMAC definition. So there has to be a way of translating the input key of length N into the native key of length 128, 192, or 256. > /The 48 byte master-secret can be generated as in TLS by the right > number of iterations and discarding the last bytes from the final > iteration. With AES-CMAC there won't be any need for that discarding. > However not clear to me why TLS chose for the key expansion already > for the master-secret when additional key expansion is done during the > Key Calculation phase ( rfc5246 section-6.3)./ > As near as I can tell, its for impedance matching. The pre-master can be agreed to (DH/ECDH) or transported (RSA) or pre-shared. All of those can be of varying lengths. So running everything through a derivation function to get 48 bytes of key for later expansion makes some sense. The other piece of it is that the master secret is used both for key expansion and as the "signing" key for the finish message. That's actually one of the bigger problems with the current scheme. In any event, since you don't know where the key bits came from and there's guidance that you shouldn't use the output of either DH or ECDH without running it through a KDF then it makes sense to do the premaster -> master derivation before using it as key bits. Mike > // > > *//* > > > > > > Yes. We stole the idea from RFC 4615 (compress the PRF key by MACing it > > > with all-zeroes AES key) and modified it slightly to get more > entropy out of > > > the key (use a counter instead of all-zeroes). RFC 4615 is from > 2006, is there > > > more experience with this approach now? > > /[SK] There is http://tools.ietf.org/html/rfc5869 with newer > recommendation on the KDF, however this is restricted to HMAC. The > NIST SP-800-56C > http://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf > recommendation is based on this RFC and does include CMAC variants. > Maybe good to look at those recommendations too./ > > // > > /There is an additional hash used in finished message (rfc5246 > section-7.4.9)/ > > /verify_data := PRF(master_secret, finished_label, > Hash(handshake_messages)) [0..verify_data_length-1];/ > > /Removing SHA-256 would mean changing this part too./ > For TLS1.2 this is a lost cause. Basically, the master secret produces both private (the key expansion key data) and public (this finished message stuff) data and does it in a way that its impossible to isolate the two. I'm in the process of drafting a replacement for the text that describes how the PRF works and that consists of changing how the key hierarchy is generated as well as moving the functions that depend on the PRF to a more standard basis. I don't know if they'll be accepted, but the current versions have issues with respect to securing them in a hardware security module. For key derivation the KDF function would be based on one of the MAC-based KDF constructs in SP800-108 an the hierarchy would change as: premaster -> finishedKey (MAC key) -> masterSecret (master key) -> clientEncrypt (encryption key) -> serverEncrypt (encryption key) -> clientMAC (MAC key) -> serverMAC (MAC key) Both the finishedKey and the masterSecret would be derived off of the premaster secret. The session keys would be derived from the masterSecret as before - but none of the IV stuff (e.g. public data). For random data derivation, we'd use the same KDF function based on the PRF function, but with a key of all '0's to produce a stream of public pseudo-random data. The finished message signature would use the pure underlying MAC function - CMAC or HMAC - and truncate that to 12 octets for the finished message tag. No key in the hierarchy would be used to produce both public and private data, and the usage of the keys would be strongly typed as either master, encryption or mac. That allows reasonable implementation of policy logic in an HSM and prevents the current class of extraction attacks. > // > > *//* > > *//* > > /Sandeep/ > > *//* > > > > > > Grüße, Carsten > > > > > > _______________________________________________ > > > dtls-iot mailing list > > > dtls-iot@ietf.org > > > https://www.ietf.org/mailman/listinfo/dtls-iot > > > ------------------------------------------------------------------------ > The information contained in this message may be confidential and > legally protected under applicable law. The message is intended solely > for the addressee(s). If you are not the intended recipient, you are > hereby notified that any use, forwarding, dissemination, or > reproduction of this message is strictly prohibited and may be > unlawful. If you are not the intended recipient, please contact the > sender by return e-mail and destroy all copies of the original message. --------------050201010401030400020402 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit
On 2/20/2014 6:56 AM, Kumar, Sandeep wrote:

Hi Lars, Carsten

 

Seems like a worthwhile initiative...see comments below

 

> -----Original Message-----

> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Carsten

> Bormann

> Sent: Monday, February 17, 2014 9:58 AM

> To: Michael StJohns

> Cc: dtls-iot@ietf.org

> Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward

> Secrecy

>

> On 17 Feb 2014, at 04:57, Michael StJohns <msj@nthpermutation.com>

> wrote:

>

> > Given that the pre-master secret for TLS could notionally be any length and

> the master secret is always 48 bytes in length, we'd need to define how to

> impedance match to the CMAC key length.

 

[SK]The pre-master secret seems to be fed as the message to the CMAC, assuming you are using the same format T := AES-CMAC(K,M,len) as in RFC4493. Then the size of the pre-master secret is not an issue and can be any long, message padding is defined in CMAC.

Um... no.  The K in AES-CMAC has to be the length of the underlying AES block cipher - either 128, 192, or 256 bits.  RFC4493 is the same as the NIST CMAC definition.  So there has to be a way of translating the input key of length N into the native key of length 128, 192, or 256.

The 48 byte master-secret can be generated as in TLS by the right number of iterations and discarding the last bytes from the final iteration. With AES-CMAC there won’t be any need for that discarding. However not clear to me why TLS chose for the key expansion already for the master-secret when additional key expansion is done during the Key Calculation phase ( rfc5246 section-6.3).


As near as I can tell, its for impedance matching.  The pre-master can be agreed to (DH/ECDH) or transported (RSA) or pre-shared.  All of those can be of varying lengths.  So running everything through a derivation function to get 48 bytes of key for later expansion makes some sense.

The other piece of it is that the master secret is used both for key expansion and as the "signing" key for the finish message.  That's actually one of the bigger problems with the current scheme.  In any event, since you don't know where the key bits came from and there's guidance that you shouldn't use the output of either DH or ECDH without running it through a KDF then it makes sense to do the premaster -> master derivation before using it as key bits.

Mike


 

>

> Yes.  We stole the idea from RFC 4615 (compress the PRF key by MACing it

> with all-zeroes AES key) and modified it slightly to get more entropy out of

> the key (use a counter instead of all-zeroes).  RFC 4615 is from 2006, is there

> more experience with this approach now?

 

[SK] There is http://tools.ietf.org/html/rfc5869 with newer recommendation on the KDF, however this is restricted to HMAC. The NIST SP-800-56C http://csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf recommendation is based on this RFC and does include CMAC variants. Maybe good to look at those recommendations too.

 

There is an additional hash used  in finished message (rfc5246 section-7.4.9)

verify_data := PRF(master_secret, finished_label, Hash(handshake_messages)) [0..verify_data_length-1];

Removing SHA-256 would mean changing this part too.


For TLS1.2 this is a lost cause.  Basically, the master secret produces both private (the key expansion key data) and public (this finished message stuff) data and does it in a way that its impossible to isolate the two.

I'm in the process of drafting a replacement for the text that describes how the PRF works and that consists of changing how the key hierarchy is generated as well as moving the functions that depend on the PRF to a more standard basis.  I don't know if they'll be accepted, but the current versions have issues with respect to securing them in a hardware security module.

For key derivation the KDF function would be based on one of the MAC-based KDF constructs in SP800-108 an the hierarchy would change as:

premaster
      -> finishedKey  (MAC key)
      -> masterSecret (master key)
              -> clientEncrypt (encryption key)
              -> serverEncrypt (encryption key)
              -> clientMAC (MAC key)
              -> serverMAC (MAC key)

Both the finishedKey and the masterSecret would be derived off of the premaster secret.  The session keys would be derived  from the masterSecret as before - but none of the IV stuff (e.g. public data).

For random data derivation, we'd use the same KDF function based on the PRF function, but with a key of all '0's to produce a stream of public pseudo-random data.

The finished message signature would use the pure underlying MAC function - CMAC or HMAC - and truncate that to 12 octets for the finished message tag.

No key in the hierarchy would be used to produce both public and private data, and the usage of the keys would be strongly typed as either master, encryption or mac.  That allows reasonable implementation of policy logic in an HSM and prevents the current class of extraction attacks.

 

Sandeep

 

>

> Grüße, Carsten

>

> _______________________________________________

> dtls-iot mailing list

> dtls-iot@ietf.org

> https://www.ietf.org/mailman/listinfo/dtls-iot


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

--------------050201010401030400020402-- From nobody Thu Feb 20 11:52:35 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 0972D1A0273 for ; Thu, 20 Feb 2014 11:52:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tSYguxg9Zj9j for ; Thu, 20 Feb 2014 11:52:29 -0800 (PST) Received: from am1outboundpool.messaging.microsoft.com (am1ehsobe001.messaging.microsoft.com [213.199.154.204]) by ietfa.amsl.com (Postfix) with ESMTP id 9D9051A0271 for ; Thu, 20 Feb 2014 11:52:26 -0800 (PST) Received: from mail37-am1-R.bigfish.com (10.3.201.254) by AM1EHSOBE023.bigfish.com (10.3.207.145) with Microsoft SMTP Server id 14.1.225.22; Thu, 20 Feb 2014 19:52:22 +0000 Received: from mail37-am1 (localhost [127.0.0.1]) by mail37-am1-R.bigfish.com (Postfix) with ESMTP id C6B0F401E6; Thu, 20 Feb 2014 19:52:22 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -31 X-BigFish: VPS-31(zz98dI15d6O9371Ic89bh148cI542I1432I9251Idb82h217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1de098h1033IL17326ah8275bh8275dh1de097h186068hz2dh109h2a8h839h947hd25hf0ah1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh1155h) Received: from mail37-am1 (localhost.localdomain [127.0.0.1]) by mail37-am1 (MessageSwitch) id 1392925939897673_6393; Thu, 20 Feb 2014 19:52:19 +0000 (UTC) Received: from AM1EHSMHS015.bigfish.com (unknown [10.3.201.249]) by mail37-am1.bigfish.com (Postfix) with ESMTP id D13E1100081; Thu, 20 Feb 2014 19:52:19 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by AM1EHSMHS015.bigfish.com (10.3.207.153) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 20 Feb 2014 19:52:19 +0000 Received: from 011-DB3MMR1-015.MGDPHG.emi.philips.com (10.128.28.99) by 011-DB3MMR1-011.MGDPHG.emi.philips.com (10.128.28.50) with Microsoft SMTP Server (TLS) id 14.3.174.2; Thu, 20 Feb 2014 19:52:18 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.12]) by 011-DB3MMR1-015.MGDPHG.emi.philips.com ([10.128.28.99]) with mapi id 14.03.0174.002; Thu, 20 Feb 2014 19:52:18 +0000 From: "Kumar, Sandeep" To: Carsten Bormann Thread-Topic: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy Thread-Index: AQHPKZjtj+qltgjdEU2o5YvDNSRTwJq41YeAgABT3ICABN+vkIAAWW4AgAAwPGA= Date: Thu, 20 Feb 2014 19:52:18 +0000 Message-ID: References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> <530188A3.7010002@nthpermutation.com> <79A752A1-F1A1-4645-8920-A4D3BF7722AA@tzi.org> <4750B796-1333-4590-A3C7-102110EF2339@tzi.org> In-Reply-To: <4750B796-1333-4590-A3C7-102110EF2339@tzi.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] Content-Type: text/plain; charset="iso-8859-1" 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/It3oxTWXRbTffFZJLAIEiITz5vc Cc: "dtls-iot@ietf.org" , Michael StJohns Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 19:52:32 -0000 > -----Original Message----- > From: Carsten Bormann [mailto:cabo@tzi.org] > Sent: Thursday, February 20, 2014 5:43 PM > > On 20 Feb 2014, at 12:56, Kumar, Sandeep > wrote: > > > [SK]The pre-master secret seems to be fed as the message to the CMAC, > assuming you are using the same format T :=3D AES-CMAC(K,M,len) as in > RFC4493. Then the size of the pre-master secret is not an issue and can b= e > any long, message padding is defined in CMAC. The 48 byte master-secret > can be generated as in TLS by the right number of iterations and discardi= ng > the last bytes from the final iteration. With AES-CMAC there won't be any > need for that discarding. However not clear to me why TLS chose for the k= ey > expansion already for the master-secret when additional key expansion is > done during the Key Calculation phase ( rfc5246 section-6.3). > > We tried to emulate the TLS 1.2 PRF, but aren't making use of any profoun= d > insights as to its construction. > Since every round of the way we are using CMAC is generating 16 bytes, we= 'll > need three rounds for the master-secret. > > > [SK] There is http://tools.ietf.org/html/rfc5869 with newer > recommendation on the KDF, however this is restricted to HMAC. The NIST > SP-800-56Chttp://csrc.nist.gov/publications/nistpubs/800-56C/SP-800- > 56C.pdf recommendation is based on this RFC and does include CMAC > variants. Maybe good to look at those recommendations too. > > RFC 4615 is essentially using the key extraction procedure defined for CM= AC > in SP-800-56C. Both have in common that they are only making use of 128 > bits of entropy; there is only a single key extraction step (which in RFC= 4615, > as recommended in SP-800-56C, is based on a public salt of 0 =3D 128 bits= of all > zeroes). While SP-800-56C does provide for the protocol to generate othe= r > salts, it does not provide for parallel key extraction steps of the form = our > proposal uses to extract more entropy. This construct is not validated b= y SP- > 800-56C. If we agree that the attempt to extract more entropy is > worthwhile, we'll have to check with CFRG whether this or another > extended extraction procedure can be used with CMAC. But since much of > the IoT world is going to 128-bit security only, maybe that's not necessa= ry in > the first place. > [SK] Indeed SP-800-56C recommends to use AES-CMAC to first extract a 128-bi= t key from the pre-master secret and then perform the expansion as a next step. TLS does this in an interleaved way to generate the 48 byte master key and = your proposal does visually matches the TLS PRF. However the PRF could also be d= efined as the combination of these two steps as in SP-800-56C avoiding the validation= question of this parallel key extraction. > (And thanks for pointing out section 7.4.9 of RFC 5246; we actually are u= sing > another CMAC here in place of the hash, but the way the key is derived fo= r > that may need to be generalized from the way we are doing this in our > implementation.) [SK] Ideally this finished message could have been a CMAC with a 128-bit ex= tracted key, however TLS only has the expanded 48 byte master key. > > Gr=FC=DFe, Carsten ________________________________ 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 Thu Feb 20 12:04: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 C493A1A01F2 for ; Thu, 20 Feb 2014 12:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 89JB3vYsoQYI for ; Thu, 20 Feb 2014 12:04:23 -0800 (PST) Received: from co9outboundpool.messaging.microsoft.com (co9ehsobe003.messaging.microsoft.com [207.46.163.26]) by ietfa.amsl.com (Postfix) with ESMTP id E96FF1A026E for ; Thu, 20 Feb 2014 12:04:22 -0800 (PST) Received: from mail215-co9-R.bigfish.com (10.236.132.241) by CO9EHSOBE024.bigfish.com (10.236.130.87) with Microsoft SMTP Server id 14.1.225.22; Thu, 20 Feb 2014 20:04:19 +0000 Received: from mail215-co9 (localhost [127.0.0.1]) by mail215-co9-R.bigfish.com (Postfix) with ESMTP id 1A031320334; Thu, 20 Feb 2014 20:04:19 +0000 (UTC) X-Forefront-Antispam-Report: CIP:157.55.7.222; KIP:(null); UIP:(null); IPV:NLI; H:mail.philips.com; RD:none; EFVD:NLI X-SpamScore: -37 X-BigFish: VPS-37(zzbb2dI98dI15d6O9371Ic89bh542Ic85dhe0eah1432I9251Idb82h217bIdd85kzz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h2189h1d1ah1d2ah21bch1fc6hzz1d7338h1de098h1033IL17326ah8275bh30d1K8275dh18c673h1de097h186068h5eeeKz2dh109h2a8h839hd25hf0ah1288h12a5h12bdh137ah1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h19ceh1ad9h1b0ah1b2fh1bceh2222h224fh1fb3h1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h20f0h2216h22d0h2336h2438h2461h2487h24ach24d7h2516h2545h255eh1155h) Received: from mail215-co9 (localhost.localdomain [127.0.0.1]) by mail215-co9 (MessageSwitch) id 1392926656738631_14178; Thu, 20 Feb 2014 20:04:16 +0000 (UTC) Received: from CO9EHSMHS004.bigfish.com (unknown [10.236.132.239]) by mail215-co9.bigfish.com (Postfix) with ESMTP id A48C546004C; Thu, 20 Feb 2014 20:04:16 +0000 (UTC) Received: from mail.philips.com (157.55.7.222) by CO9EHSMHS004.bigfish.com (10.236.130.14) with Microsoft SMTP Server (TLS) id 14.16.227.3; Thu, 20 Feb 2014 20:04:15 +0000 Received: from 011-DB3MPN1-025.MGDPHG.emi.philips.com ([169.254.5.12]) by 011-DB3MMR1-004.MGDPHG.emi.philips.com ([10.128.28.54]) with mapi id 14.03.0174.002; Thu, 20 Feb 2014 20:03:20 +0000 From: "Kumar, Sandeep" To: Michael StJohns , Carsten Bormann Thread-Topic: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy Thread-Index: AQHPKZjtj+qltgjdEU2o5YvDNSRTwJq41YeAgABT3ICABN+vkIAAeqYAgAATorA= Date: Thu, 20 Feb 2014 20:03:19 +0000 Message-ID: References: <20140214151044.9603.20079.idtracker@ietfa.amsl.com> <530188A3.7010002@nthpermutation.com> <79A752A1-F1A1-4645-8920-A4D3BF7722AA@tzi.org> <53064C80.6040606@nthpermutation.com> In-Reply-To: <53064C80.6040606@nthpermutation.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [85.150.192.178] Content-Type: multipart/alternative; boundary="_000_BE6D13F6A4554947952B39008B0DC0153E561FEA011DB3MPN1025MG_" 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/JwXMOB9CvknDXn92m6DjCZW7rQQ Cc: "dtls-iot@ietf.org" Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward Secrecy X-BeenThere: dtls-iot@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DTLS for IoT discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Feb 2014 20:04:28 -0000 --_000_BE6D13F6A4554947952B39008B0DC0153E561FEA011DB3MPN1025MG_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Michael StJohns [mailto:msj@nthpermutation.com] Sent: Thursday, February 20, 2014 7:42 PM On 2/20/2014 6:56 AM, Kumar, Sandeep wrote: Hi Lars, Carsten Seems like a worthwhile initiative...see comments below > -----Original Message----- > From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Carsten > Bormann > Sent: Monday, February 17, 2014 9:58 AM > To: Michael StJohns > Cc: dtls-iot@ietf.org > Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Cipher Suites with Forward > Secrecy > > On 17 Feb 2014, at 04:57, Michael StJohns > > wrote: > > > Given that the pre-master secret for TLS could notionally be any length= and > the master secret is always 48 bytes in length, we'd need to define how t= o > impedance match to the CMAC key length. [SK]The pre-master secret seems to be fed as the message to the CMAC, assum= ing you are using the same format T :=3D AES-CMAC(K,M,len) as in RFC4493. T= hen the size of the pre-master secret is not an issue and can be any long, = message padding is defined in CMAC. Um... no. The K in AES-CMAC has to be the length of the underlying AES blo= ck cipher - either 128, 192, or 256 bits. RFC4493 is the same as the NIST = CMAC definition. So there has to be a way of translating the input key of = length N into the native key of length 128, 192, or 256. [SK] True K has to be the AES key length, but the key K used during extract= ion is all 0 (or the counter here), and the length N pre-master (agreed (D= H/ECDH) or transported (RSA) or pre-shared) is the message M of AES-CMAC w= hich could be any length. Do not see the impedance mismatch here. This is a= lso what is suggested in SP-800-56C for the extraction stage. During the ex= pansion stage, the key for AES-CMAC is the extracted 128-bit key. The curre= nt proposal does something similar in an interleaved parallel way. The 48 byte master-secret can be generated as in TLS by the right number of= iterations and discarding the last bytes from the final iteration. With AE= S-CMAC there won't be any need for that discarding. However not clear to me= why TLS chose for the key expansion already for the master-secret when add= itional key expansion is done during the Key Calculation phase ( rfc5246 se= ction-6.3). As near as I can tell, its for impedance matching. The pre-master can be a= greed to (DH/ECDH) or transported (RSA) or pre-shared. All of those can be= of varying lengths. So running everything through a derivation function t= o get 48 bytes of key for later expansion makes some sense. The other piece of it is that the master secret is used both for key expans= ion and as the "signing" key for the finish message. That's actually one o= f the bigger problems with the current scheme. In any event, since you don= 't know where the key bits came from and there's guidance that you shouldn'= t use the output of either DH or ECDH without running it through a KDF then= it makes sense to do the premaster -> master derivation before using it as= key bits. Mike > > Yes. We stole the idea from RFC 4615 (compress the PRF key by MACing it > with all-zeroes AES key) and modified it slightly to get more entropy out= of > the key (use a counter instead of all-zeroes). RFC 4615 is from 2006, is= there > more experience with this approach now? [SK] There is http://tools.ietf.org/html/rfc5869 with newer recommendation = on the KDF, however this is restricted to HMAC. The NIST SP-800-56C http://= csrc.nist.gov/publications/nistpubs/800-56C/SP-800-56C.pdf recommendation i= s based on this RFC and does include CMAC variants. Maybe good to look at t= hose recommendations too. There is an additional hash used in finished message (rfc5246 section-7.4.= 9) verify_data :=3D PRF(master_secret, finished_label, Hash(handshake_messages= )) [0..verify_data_length-1]; Removing SHA-256 would mean changing this part too. For TLS1.2 this is a lost cause. Basically, the master secret produces bot= h private (the key expansion key data) and public (this finished message st= uff) data and does it in a way that its impossible to isolate the two. I'm in the process of drafting a replacement for the text that describes ho= w the PRF works and that consists of changing how the key hierarchy is gene= rated as well as moving the functions that depend on the PRF to a more stan= dard basis. I don't know if they'll be accepted, but the current versions = have issues with respect to securing them in a hardware security module. For key derivation the KDF function would be based on one of the MAC-based = KDF constructs in SP800-108 an the hierarchy would change as: premaster -> finishedKey (MAC key) -> masterSecret (master key) -> clientEncrypt (encryption key) -> serverEncrypt (encryption key) -> clientMAC (MAC key) -> serverMAC (MAC key) Both the finishedKey and the masterSecret would be derived off of the prema= ster secret. The session keys would be derived from the masterSecret as b= efore - but none of the IV stuff (e.g. public data). For random data derivation, we'd use the same KDF function based on the PRF= function, but with a key of all '0's to produce a stream of public pseudo-= random data. The finished message signature would use the pure underlying MAC function -= CMAC or HMAC - and truncate that to 12 octets for the finished message tag= . No key in the hierarchy would be used to produce both public and private da= ta, and the usage of the keys would be strongly typed as either master, enc= ryption or mac. That allows reasonable implementation of policy logic in a= n HSM and prevents the current class of extraction attacks. Sandeep > > Gr=FC=DFe, Carsten > > _______________________________________________ > 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. --_000_BE6D13F6A4554947952B39008B0DC0153E561FEA011DB3MPN1025MG_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

 

 

From: Michael StJohns [mailto:msj@nthpermutation.com]
Sent: Thursday, February 20, 2014 7:42 PM

 

On 2/20/2014 6:56 AM, Kumar, Sandeep wrote:

Hi Lars, Carsten

 <= /o:p>

Seems like a worthw= hile initiative...see comments below

 

> -----Original Message-----

> From: dtls-iot [mailto:dtls-iot-bounces@ietf.org] On Behalf Of Carsten=

> Bormann

> Sent: Monday, February 17, 2014 9:58 AM=

> To: Michael StJohns

> Cc: dtl= s-iot@ietf.org

> Subject: Re: [Dtls-iot] ECDHE-PSK AES-CCM Ci= pher Suites with Forward

> Secrecy

>

> On 17 Feb 2014, at 04:57, Michael StJohns &l= t;msj@nthpermutation.com>

> wrote:

>

> > Given that the pre-master secret for TL= S could notionally be any length and

> the master secret is always 48 bytes in leng= th, we'd need to define how to

> impedance match to the CMAC key length.=

 

[SK]The pre-mast= er secret seems to be fed as the message to the CMAC, assuming you are usin= g the same format T :=3D AES-CMAC(K,M,len) as in RFC4493. Then the size of = the pre-master secret is not an issue and can be any long, message padding is defined in CMAC.

Um... no.  The K in AES-CMAC ha= s to be the length of the underlying AES block cipher - either 128, 192, or= 256 bits.  RFC4493 is the same as the NIST CMAC definition.  So there has to be a way of translating the input key of length N into the= native key of length 128, 192, or 256.

[SK] True K has = to be the AES key length, but the key K used during extraction is all 0 (or= the counter here), and the length N pre-master (agreed  (DH/ECDH) or = transported (RSA) or pre-shared) is the  message M of AES-CMAC which could be any length. Do not see the impedance mismatch= here. This is also what is suggested in SP-800-56C for the extraction stag= e. During the expansion stage, the key for AES-CMAC is the extracted 128-bi= t key. The current proposal does something similar in an interleaved parallel way.

The 48 byte mast= er-secret can be generated as in TLS by the right number of iterations and = discarding the last bytes from the final iteration. With AES-CMAC there won= ’t be any need for that discarding. However not clear to me why TLS chose for the key expansion already for th= e master-secret when additional key expansion is done during the Key Calcul= ation phase ( rfc5246 section-6.3).


As near as I can tell, its for impedance matching.  The pre-master can= be agreed to (DH/ECDH) or transported (RSA) or pre-shared.  All of th= ose can be of varying lengths.  So running everything through a deriva= tion function to get 48 bytes of key for later expansion makes some sense.

The other piece of it is that the master secret is used both for key expans= ion and as the "signing" key for the finish message.  That's= actually one of the bigger problems with the current scheme.  In any = event, since you don't know where the key bits came from and there's guidance that you shouldn't use the output of either DH o= r ECDH without running it through a KDF then it makes sense to do the prema= ster -> master derivation before using it as key bits.

Mike



 

>

> Yes.  We stole the idea from RFC 4615 (= compress the PRF key by MACing it

> with all-zeroes AES key) and modified it sli= ghtly to get more entropy out of

> the key (use a counter instead of all-zeroes= ).  RFC 4615 is from 2006, is there

> more experience with this approach now?=

 

[SK] There is http://tools.ietf.org/html/rfc5869= with newer recommendation on the KDF, however this is restricted to HMAC. = The NIST SP-800-56C http://csrc.nist.gov/publications/nistpubs= /800-56C/SP-800-56C.pdf recommendation is based on this RFC and = does include CMAC variants. Maybe good to look at those recommendations too.

 

There is an addi= tional hash used  in finished message (rfc5246 section-7.4.9)

verify_data :=3D PRF(master_secret, finished_label, Hash(handsha= ke_messages)) [0..verify_data_length-1];

Removing SHA-256= would mean changing this part too.


For TLS1.2 this is a lost cause.  Basically, the master secret produce= s both private (the key expansion key data) and public (this finished messa= ge stuff) data and does it in a way that its impossible to isolate the two.=

I'm in the process of drafting a replacement for the text that describes ho= w the PRF works and that consists of changing how the key hierarchy is gene= rated as well as moving the functions that depend on the PRF to a more stan= dard basis.  I don't know if they'll be accepted, but the current versions have issues with respect to securing= them in a hardware security module.

For key derivation the KDF function would be based on one of the MAC-based = KDF constructs in SP800-108 an the hierarchy would change as:

premaster
      -> finishedKey  (MAC key)
      -> masterSecret (master key)
            &nb= sp; -> clientEncrypt (encryption key)
              -> = serverEncrypt (encryption key)
              -> clien= tMAC (MAC key)
              -> serve= rMAC (MAC key)

Both the finishedKey and the masterSecret would be derived off of the prema= ster secret.  The session keys would be derived  from the masterS= ecret as before - but none of the IV stuff (e.g. public data).

For random data derivation, we'd use the same KDF function based on the PRF= function, but with a key of all '0's to produce a stream of public pseudo-= random data.

The finished message signature would use the pure underlying MAC function -= CMAC or HMAC - and truncate that to 12 octets for the finished message tag= .

No key in the hierarchy would be used to produce both public and private da= ta, and the usage of the keys would be strongly typed as either master, enc= ryption or mac.  That allows reasonable implementation of policy logic= in an HSM and prevents the current class of extraction attacks.


 

Sandeep

 

>

> Gr=FC=DFe, Carsten

>

> ____________________________________________= ___

> dtls-iot mailing list

> dtls-iot@ietf.org=

> https://www.ietf.org/= mailman/listinfo/dtls-iot

 

The information contained in th= is 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 proh= ibited and may be unlawful. If you are not the intended recipient, please c= ontact the sender by return e-mail and destroy all copies of the original message.

 

--_000_BE6D13F6A4554947952B39008B0DC0153E561FEA011DB3MPN1025MG_-- From nobody Tue Feb 25 06:07: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 459641A072D for ; Tue, 25 Feb 2014 06:07:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.929 X-Spam-Level: X-Spam-Status: No, score=-0.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_DE=0.35, SPF_HELO_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q9WdjazpSaYc for ; Tue, 25 Feb 2014 06:07:46 -0800 (PST) Received: from informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) by ietfa.amsl.com (Postfix) with ESMTP id C01251A0732 for ; Tue, 25 Feb 2014 06:07:42 -0800 (PST) X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de Received: from smtp-fb3.informatik.uni-bremen.de (smtp-fb3.informatik.uni-bremen.de [134.102.224.120]) by informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id s1PE7VwD012781 for ; Tue, 25 Feb 2014 15:07:31 +0100 (CET) Received: from mail-ve0-f170.google.com (mail-ve0-f170.google.com [209.85.128.170]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp-fb3.informatik.uni-bremen.de (Postfix) with ESMTPSA id 6FBF37D1 for ; Tue, 25 Feb 2014 15:07:31 +0100 (CET) Received: by mail-ve0-f170.google.com with SMTP id c14so469193vea.1 for ; Tue, 25 Feb 2014 06:07:30 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=mime-version:from:date:message-id:subject:to:content-type; bh=p8NK2Mw/bIyla3E9E/oLyoQZAWZ04DobHRXa3TlfoQE=; b=GVUUeREDYtCl4IhyiKf/mMBIUUsrF7gK8o9b7tMkSrGkIwxfnq7jmDBJnOEGijoGoj Y/K0LD4J+Z6zuQnS8kre6dpR0QQ2F7QjAxaRzpBVmjdZ4zpPG4BWRQHXYbnVEjgDyXcO duJ/R6keNwzq8fHnQYwKTRAdW90yYmw8BsRHg3lkW+iTRvJ/ZU5NMwThmSWsXVRULAGv FhABN2RA0i7Xdn18CxUdiyL1eRsf1lQAKUJM6Pm8bINi6Z14Ij9OcWK+QlX2eem0DGix e1ptmj+eSy/OdrsrikUl9SddnAMEcC0cCG04gF630roPzTJKDAV4muP3qHzXOAzAAM4f /59Q== X-Received: by 10.220.161.132 with SMTP id r4mr1312291vcx.29.1393337250324; Tue, 25 Feb 2014 06:07:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.52.53.227 with HTTP; Tue, 25 Feb 2014 06:06:50 -0800 (PST) From: Klaus Hartke Date: Tue, 25 Feb 2014 15:06:50 +0100 Message-ID: To: "dtls-iot@ietf.org" Content-Type: text/plain; charset=ISO-8859-1 Archived-At: http://mailarchive.ietf.org/arch/msg/dtls-iot/Oes7kV_kUAVi-TpHcyKxrHb71r0 Subject: [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: Tue, 25 Feb 2014 14:07:50 -0000 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