Subject: Re: [Dtls-iot] DICE charter discussion - what is in scope, what is next?

From: Corinna Schmitt <[email-masked]>
Date: Mon, 08 Jul 2013 10:09:54 +0200

Dear Zach,
  
  next time it goes directly on the list ;-) And thanks for adding our draft.
  
  Regards,
  Corinna

  > Am 08.07.13 09:42, schrieb Zach Shelby:
>> Oh, and please send your comment to the public mailing list too! We need more list traffic - so public discussion is very good right now.
>>
>> Zach
>>
>> On Jul 8, 2013, at 10:41 AM, Corinna Schmitt
>> <[email-masked]>
>>  wrote:
>>
>>
>>> Dear Zach,
>>>
>>> thanks for organizing the BOF.
>>>
>>> Just a short comment:
>>> In your document you mention existing work. Here I miss our submission draft-schmitt-two-way-authentication-for-iot-00.txt. I announced it July 4th.
>>> Please, add it to DICE. I can also make a short presentation if you want.
>>>
>>> Regards,
>>> Corinna
>>>
>>> Am 08.07.13 09:36, schrieb Zach Shelby:
>>>
>>>> Hi Everyone,
>>>>
>>>> Hope folks are having a great summer running up to IETF Berlin. Carsten and I, along with your our helpful security area AD, Stephen Farrel, got together recently to plan the BOF agenda and proposed charter for DICE. Now it is time to give you feedback!
>>>>
>>>> As a reminder, we have been storing working drafts of our material here:
>>>>
>>>>
>>>> https://docs.google.com/document/d/1Gw00WXRgjJJQJMv9seVpuXuLtIDYKhHE-7pX4eDo3g8
>>>>
>>>>
>>>>
>>>> There are a few important things to discuss now:
>>>>
>>>> 1. It seems pretty obvious that DTLS profiling is our first and main goal. We haven't heard any controversy around that. However the second WG item that we have discussed and is currently in the charter is to re-use the DTLS record layer for use with group keys and multicast. However simple that sounds to many of us, based on the IESG and previous TLS WG feedback we have received, to many security folks the word "multicast" opens up a can of worms that may cause us plenty of problems in focusing the BOF discussion and first charter. My proposal is that we drop the multicast WG item from this first charter, and take it on when re-chartering. Do folks agree?
>>>>
>>>> 2. Several things have been identified as rechartering items, please tell us if we missed something. During the BOF we do want to point out what our future would could be:
>>>>
>>>> * There has been talk about also going beyond just profiling DTLS and actually defining a new TLS over CoAP handshake transport. To be clear, this would not be part of this first profiling work item. However this is something we could consider for rechartering based on some more work being done in parallel showing the possible benefits of this approach.
>>>>
>>>> * Quite a few folks are interested in revocation (which often means white/black list configuration in our use cases) for constrained devices. We discussed that this is definitely an interesting subject for rechartering. In the mean time, you might want to take a look at the OMA Lightweight M2M standard, as this defines white list ACL management for CoAP.
>>>>
>>>> * David McGrew has also proposed that we could define how to use (in the profile) or possibly work on new cipher suites for constrained device use wit hTLS. This is also a very interesting area to consider - although the actually work might occur in e.g. the TLS working group.
>>>>
>>>> 3. Any comments to improve the general charter text or regarding work item timelines would be helpful.
>>>>
>>>> After we nail down the first charter scope, we can discuss the BOF agenda. We have a really tight 1 hour BOF, so it needs to stay focused.
>>>>
>>>>
>>>> Draft Charter
>>>> -----------------
>>>>
>>>> Draft Charter – DTLS In Constrained Environments (DICE)
>>>>
>>>> There is an increased use of wireless control networks in city infrastructure, environmental monitoring, industrial automation, and building management systems.  These wireless control networks comprise many electronic devices, sensors and actuators that are connected to each other, and in most cases Internet connected, thus creating a trend towards Internet of Things (IoT). The CoRE working group has defined a framework for resource-oriented applications intended to run on constrained node networks (see I-D-ietf-lwig-terminology). This connects devices which are constrained by power, limited amount of code size and memory in a network with severe limits on throughput. The Constrained Application Protocol (CoAP) can be used to manipulate resources on a device these environments.
>>>> Group communication is an important feature as it can be effectively used to convey messages to a group of devices without requiring the sender to perform multiple time- and energy-consuming unicast transmissions, one for each group member.  For example, in a building control management system, Heating, Ventilation and Air-Conditioning (HVAC) and lighting devices can be grouped according to the layout of the building, and control commands can be issued to a group of devices.  Unsecured group communication for CNNs is enabled by using CoAP on top of IP-multicast. However, it must be secured as it is vulnerable to the usual attacks (eavesdropping, tampering, message forgery, replay, etc).  Datagram Transport Layer Security (DTLS) has been chosen by CoRE to protect CoAP unicast communications, and it would be beneficial if the same security protocol, i.e., DTLS can be used to protect CoAP group communication as well. The goal of the DICE working group is to ensure that DTLS is t
>>>>  he obviou
>>>> s choice for protecting CoAP and other UDP based protocols for the Internet of Things.
>>>> The current design of DTLS leads to fragmentation of DTLS handshake messages over the wireless link, in particular when Raw Public-key and Certificate modes are used. From the various implementation experiences reported in the LWIG working group, the complexity of re-transmission and re-ordering of DTLS handshake messages in constrained networks has resulted in a significantly increased code size and RAM. Additional reliability mechanisms for transporting DTLS handshake messages are required as they will ensure that handling of re-ordered messages needs to be done in a single place in the stack only. This working group will also look at shim layer functions such as header compression and transports needed to use DTLS efficiently.
>>>>
>>>> This WG combines expertise from both the IETF Application and Security areas in order to work out the appropriate security solutions for the Internet of Things. DICE will work closely with LWIG to understand the complexity and overhead issues of DTLS, and to investigate the performance issues of the DTLS handshake.
>>>>
>>>> The scope of this WG is to define the following:
>>>> 	
>>>> 1. Document the problems with the DTLS handshake for IoT, and define a suitable profile of DTLS for an IoT architecture and use case that minimizes the complexity and overhead of DTLS for constrained devices. The set of DTLS extensions and modes to be supported will be defined.
>>>>
>>>> 2. The use of DTLS Record Layer in combination with the (derived) multicast key for select cipher suites to protect the CoAP group communication without source authentication. The DTLS Record Layer should not be modified/altered.
>>>> (TBD: Multicast has some technical concern if we are dealing with key exchange and key updates, or changing TLS. Do it via re-chartering?)
>>>>
>>>> Goals and Milestones
>>>>
>>>> Oct 2013        WG document for DTLS for Constrained Environments profile
>>>> Nov 2013       WG document for secure multicast group communication for IoT (TBD)
>>>> Feb 2014       DTLS for IoT profile specification submitted to the IESG for publication as standards track
>>>> Mar 2014       Secure Multicast group communication specification submitted to the IESG for publication as informational (TBD)
>>>>

--