DTLS In Constrained Environments
charter-ietf-dice-01

Changed charter milestone "DTLS for IoT profile specification submitted to the IESG for publication as standards track", set due date to May 2014 from May 2013

[Ballot comment]
Thanks for addressing my BLOCK.

I always prefer when the proposed milestones (document, intended status, and target dates) are populated.
It helps the work assessment and review.
Important note: the milestones are not part of the charter text, which is THE contract between the IESG and the WG.
Since we don't have consensus on this topic within the IESG, it's just a nice-to-have, and up to the responsible AD ...

[Ballot comment]
Thanks for addressing my DISCUSS.

I always prefer when the proposed milestones (document, intended status, and target dates) are populated.
It helps the work assessment and review.
Important note: the milestones are not part of the charter text, which is THE contract between the IESG and the WG.
Since we don't have consensus on this topic within the IESG, it's just a nice-to-have, and up to the responsible AD ...

[Ballot block]
It's more a RFC (Request For Clarification) than a BLOCK.
The current charter speaks about "constrained environments", "device in constrained environments", "constrained devices", "Internet of Things environments"
I'm not sure if DICE will focus on:
1. constrained devices
2. constrained networks
3. both constrained devices and networks
When we discussed http://tools.ietf.org/html/draft-ersue-constrained-mgmt-03, this was an important distinction.
Please clarify, and update the charter accordingly.

Disclaimer: Not even sure if it makes a difference from a DTLS protocol point of view (admittedly, I don't know much about DTLS)

[Ballot comment]
I always prefer when the proposed milestones (document, intended status, and target dates) are populated.
It helps the work assessment and review.
Important note: the milestones are not part of the charter text, which is THE contract between the IESG and the WG.
Since we don't have consensus on this topic within the IESG, it's just a nice-to-have, and up to the responsible AD ...

[Ballot comment]
Small suggestions that I hope are non-controversial:

- The first two tasks sound like the protocol work. It seems to me that the 5th paragraph ("The DTLS state machine should not be modified...") belongs between the second and third task, since it doesn't really apply to the third task. You might even start the sentence, "With regard to the above two items of protocol work, the DTLS state machine...".

- I take the third task to involve writing a report on the findings of the "investigation". I think simply ending the first sentence with "and report on those findings" would be sufficient.

[Ballot comment]
The new multicast text is much better.  I think it would be clearer if it could say explicitly that there they're considering a no-handshake mode of DTLS, but I can live with it as-is.

[Ballot comment]
I agree with most IESG feedback.

Quoting Adrian: "It would appear that substantial rewrite is in the pipe. I am holding my review
until then.".

However, one new point on the table now.

    Group communication is an important feature in IoT applications 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.

Does we imply that HVAC is an IoT application?
Does we imply here that HVAC will be using CoAP?
I would be careful about those implicit assertions, specifically the second one. We will see how the industry will evolve: BACNET [ASHRAE], MODBUS, EMAN [IETF], CIP [ODVA], etc...

Lighting devices is a good example though.

[Ballot block]
I'm concerned about the second bullet under "scope".  Two things:

(1) It's not clear what's meant by "state machine" in this context.  Do you mean the DTLS "Timeout and Retransmission State Machine" in RFC 6347 (Figure 3)?  (That's the only use of that phrase I find in the DTLS or TLS specs.)  It seems like what's meant is something broader, involving the use of handshake, change-cipher-suite, etc.

(2) In a similar vein, it seems like the second bullet is basically defining the direct use of the TLS record layer, without using the handshake to negotiate keys.  That seems like rather a radical departure from the normal mode of operation for DTLS, which seems like it would violate the requirement of leaving the state machine alone.  Or am I being too twitchy here, and they really just want to use the PSK ciphersuites?  Even then, it's not immediately clear to me that the handshake would work in a multicast / group keying context.

[Ballot block]
Damn, that third paragraph is a killer.  I'm elevating Ted's comment about the huge chunk of text to a block -- this charter can't go out for review in this state.  I have no objection to what's being proposed here, but it needs to be edited so it isn't so long, rambling, and dense.

[Ballot comment]
I wholeheartedly support this work going forward. However, if Barry would not already hold a "Block" comment on the text for the charter, I would have placed one myself. The third paragraph is not good, and in fact, the whole charter reads rather badly. Abbreviations used in the text are not defined (CNN). And I think the text oversells the difficulties, and fails to make clear some things that people are asking about (such as focus on transport solutions).

Anyway, the only substantial comment that I have is related to group communication. I'm not entirely sure it is sensible to define the record layer usage for multicast without simultaneously tackling session setup and key management. But if you think that is the right approach, go ahead.

Here's a shorter version of the charter text from what I understand the group wants to do.

This working group focuses on supporting transport-layer security solution, i.e., DTLS (rfc NNNN) in constrained environments. The first task of the working group is to define a DTLS profile that is suitable for Internet of Things applications and is reasonably implementable on many small devices.

The second task of the working group is to define how DTLS record layer can be used to transmit multicast messages securely. Key management and session setup is out of scope of the working in its initial stage, however. Security for these multicast messages is needed in many Internet of Things environments, as some messages are commonly multicast among a set of receivers.

The third task of the working group is to investigate practical issues around DTLS handshake in constrained environments. Many current systems end up fragmenting messages, and the  re-transmissionand re-ordering of the handshake messages results in significant complexity and reliability problems.  Additional reliability mechanisms for transporting DTLS handshake messages are required as they will ensure that handling of re-ordered messages needs to be done only once in a single place in the stack. This working group may also look at alternative TLS transports in cooperation with the TLS WG.

[Ballot block]
Damn, that third oaragraph is a killer.  I'm elevating Ted's comment about the huge chunk of text to a block -- this charter can't go out for review in this state.  I have no objection to what's being proposed here, but it needs to be edited so it isn't so long, rambling, and dense.

[Ballot comment]
I agree with Spencer's suggested re-wording.

Based on the presumption that (D)TLS is the answer, should the charter specifically say it is focused on transport-layer security approaches and that IPsec-based approaches are too resource intensive?  In other words, the charter *sounds* like it is ruling out solutions based on RFCs 6407, 4046, etc. for the multicast-related security and IPsec for unicast security.

[Ballot comment]
This charter needs more paragraph breaks and more organization—it's a huge chunk to digest all at once.

Does this:
  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.
mean this:
  The goal of the DICE working group is to eliminate
  obstacles to the choice of DTLS in protecting CoAP
  and other UDP based protocols for the IoT.
?

Otherwise it sounds like you're staking territory, which I assume is not the intent.

What are the ???s at the bottom of the charter?  Is the working group uncertain of these charter items?

[Ballot comment]
I really struggled to understand this text.

"Over the past few years, there have been many efforts to implement DTLS on
embedded systems in order to support Internet of Things (IoT) applications. In
fact, Transport Layer    Security (TLS) and its datagram variant were both
invented for use in the Internet-based web applications, and implementers face
many challenges to deploy (D)TLS on IoT devices that are limited in memory
resources (RAM, Flash), CPU and power. In particular, (D)TLS supports a wide
range of security features and functionalities, some of these features are not
necessarily required for IoT applications. One of the goals of DICE working
group is to document the immediate problems that hinder the deployment of DTLS
on embedded systems and proposes a DTLS profile for CoAP-based IoT applications
based on well understood application use cases."

I'm not suggesting what follows as a paraphrase, I'm just curious if I'm understanding it now.

"DTLS, like its connection-oriented predecessor Transport Layer Security (TLS), was invented for use with Internet-based web applications on relatively powerful platforms. Recent efforts to implement DTLS on embedded systems in order to support Internet of Things (IoT) applications have encountered many challenges with IoT devices that are limited in memory resources (RAM, Flash), CPU and power. One of the goals of the DICE working group is to document the immediate problems that hinder the deployment of DTLS on embedded systems and proposes a DTLS profile for CoAP-based IoT applications based on well understood application use cases. In particular, (D)TLS supports a wide range of security features and functionalities, and some of these features are not necessarily required for IoT applications."

At a minimum, "In particular, (D)TLS supports a wide range of security features and functionalities, some of these features are not necessarily required for IoT applications." is a run-on sentence.