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

From: Zach Shelby <[email-masked]>
Date: Mon, 8 Jul 2013 10:36:38 +0300

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 the obvious 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)

-- 
Zach Shelby, Chief Nerd, Sensinode Ltd.
http://www.sensinode.com @SensinodeIoT
Mobile: +358 40 7796297
Twitter: @zach_shelby
LinkedIn: http://fi.linkedin.com/in/zachshelby
6LoWPAN Book: http://6lowpan.net

---

From: peter van der Stok <[email-masked]>
Date: Mon, 08 Jul 2013 09:58:35 +0200

Hi Zach and others,

Many thanks for all the preparatory work.
I like to react to your item 1

> 
> 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?
> 

I tend to disagree.
One of the major reasons to start this BoF is the MC aspect.
By dropping it from the charter I don't expect the opposition to MC from 
the security people to fade away.
Keeping momentum, the wg might make an inventory of the MC security 
threats and discuss their relevance in our context.
I have no idea if this is doable or may help making the security aspects 
to MC digestible.

Greetings,

peter

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Mon, 8 Jul 2013 08:41:28 +0000

Hi Zach

Again thanks for preparation!

I too have to disagree with dropping multicast. This does not solve the main reason why we came to the discussion of creating this BoF in the first place. The idea was to come up with a multicast solution that is needed by the industry. We have presented a solution using DTLS without changing the DTLS protocol in the TLS group and as far as we remember the response from the TLS group was positive, their impression was this should be addressed but not within the TLS group..   By postponing the issue it does not take away the concerns security folks have. I would suggest to keep this in the charter for now and discuss our revised draft and see how people respond.

Regards
Sandeep

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of peter van der Stok
Sent: Monday, July 08, 2013 9:59 AM
To: [email-masked]
Subject: Re: [Dtls-iot] DICE charter discussion - what is in scope, what is next?

Hi Zach and others,

I tend to disagree.
One of the major reasons to start this BoF is the MC aspect.
By dropping it from the charter I don't expect the opposition to MC from the security people to fade away.
Keeping momentum, the wg might make an inventory of the MC security threats and discuss their relevance in our context.
I have no idea if this is doable or may help making the security aspects to MC digestible.

Greetings,

peter

_______________________________________________
dtls-iot mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtls-iot

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

---

From: Zach Shelby <[email-masked]>
Date: Mon, 8 Jul 2013 12:11:21 +0300

Sandeep, Peter,

Personally, I also would like to see the record-layer use of multicast solved by DICE as soon as possible.

However, there is a pretty good risk that including multicast in the BOF will derail the discussion. Remember, most people coming to a BOF have not read our charter or drafts before showing up. They will not realise that when we talk about multicast, we are not proposing to change the DTLS record layer nor trying to solve the group key management problem. Although we had some positive feedback from the TLS WG, we also heard a fair amount of concern that the problem is a lot harder to solve than we think. 

Obviously those of us that have worked on the subject and really need to feature agree we should do this. 

- Do other folks have ideas on how we can include the proposed multicast record layer work item in this charter? 
- Is the charter clear enough? 
- How to approach this in the BOF without derailing the discussion? 
- Are there people on the list that think we should not work on multicast at all (even with this narrow scope)?  

Thanks,
Zach

---

From: "Keoh, Sye Loong" <[email-masked]>
Date: Mon, 8 Jul 2013 09:59:45 +0000

Hi Zach,

I also disagree to drop the multicast security from the charter. 

It's true that most people coming to the BoF may not have read the charter and the relevant drafts. But, it should be the responsibility of the presenter and the chairs to clarify the scope to the audience, so that the discussion is relevant and not derailed.  The presenter and the chairs can stress that the multicast security that we are talking about does not propose changing the DTLS record layer, and not addressing the group key management. 

Secondly, there are many companies which are interested in a secure multicast solution for the IoT, or essentially CoAP-based multicast solution. A preliminary solution has been presented, and given that there are so many security experts in IETF, we are confident that a feasible solution can be devised.

Cheers
Sye Loong 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Zach Shelby
Sent: maandag 8 juli 2013 11:11
To: Kumar, Sandeep
Cc: [email-masked]
Subject: Re: [Dtls-iot] DICE charter discussion - what is in scope, what is next?

Sandeep, Peter,

Thanks,
Zach

On Jul 8, 2013, at 11:41 AM, "Kumar, Sandeep" <[email-masked]> wrote:

>> 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?
>> 
> 
> I tend to disagree.

---

From: Zach Shelby <[email-masked]>
Date: Mon, 8 Jul 2013 15:53:50 +0300

Guys,

Good to see all the support for the multicast record layer feature.

Is there anyone opposed to including multicast support in the first charter, or who sees an unreasonable risk in doing so? 

If not, then I am fine with keeping it in the charter. However we need some good ideas on how to explain the DICE goals in the BOF and introduce the proposed work item. Should we even be talking about multicast as a title? I mean, really this is about using group keys with the DTLS record layer without modifying it. Should we just be talking about "group keys and the standard DTLS record layer"? We are already proposing an informational RFC.

Do folks think the current straw-man is a good starting point? Please take a look and give your feedback:

http://www.ietf.org/id/draft-keoh-dtls-multicast-security-00.txt

Zach

---

From: Michael Richardson <[email-masked]>
Date: Mon, 08 Jul 2013 10:08:30 -0400

> Draft Charter – DTLS In Constrained Environments (DICE)

I suggest that the mailing list get renamed sooner rather than later.

    > 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?)

I was thinking this morning that there are some potential code, table, and
on-the-air byte savings to be had if the record layer is open to some
redefinition. Perhaps we could call it compression (because that's what it
would be).

In particular, MPL maintains a Buffered Message Set and MinSequence.
Meanwhile, DTLS maintains an IPsec-ESP-like receive window.  For multiple
transmitter (i.e. multiple source) multicasted ESP, one has normally turned
off replay protection.  I believe that everyone (all 5 of the people in the
lab?!?) who implemented multicast IPsec probably turned off reply protection
for single source multicast too.

These do the same thing.

If one does the processing in a strictly layed approach,  the MPL
MinSequence/BufferedMessageSet will mean that one will never see the same
DTLS layer multicast message twice.  In IPsec ESP land, we were very careful
to specify that the receive window checks occur before the cryptographic
operations such that a node(mote) could not be DOS'es by repeating (valid)
packets at it.

On the other hand, if one did the cryptographic validation first (with the
sequence number check first), one could get a level of DOS protection above
and beyond what MPL provides.

The point is that the check for having seen the packet twice need only be
done once, and one might as well do it securely.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

--
Michael Richardson <[email-masked]>, Sandelman Software Works