Subject: [Dtls-iot] Mail regarding draft-keoh-tls-multicast-security status

From: "Thanos, Daniel (GE Energy Management)" <[email-masked]>
Date: Mon, 8 Jul 2013 15:10:24 +0000

Greetings All-

My name is Daniel Thanos, I work for GE Grid Automation. It has been brought to my attention that multicast security maybe dropped from the DTLS charter for IoT. I would like to voice my support for keeping multicast security in the charter. I am working in the area of Distributed Automation for Smart Gird and in next generation communications/security and there will be a need to for multicast/group key management because of the nature of some automation protocols that we want to move into these network environments. Is there way to keep this in the charter? GE together with Philips is will willing to help lead this work.

Many Thanks

Daniel Thanos
Chief Cyber Security Architect
GE Grid Automation
Product Research and Development

T +1 905 927 5439
F +1 905 201 2098
C +1 647 283 6499
E [email-masked]<mailto:[email-masked]>
www.gedigitalenergy.com<http://www.gedigitalenergy.com>

650 Markland Street
Markham, ON, L6E 0M1
Canada

---

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

Hi Daniel,

Thanks for your feedback. This is exactly the kind of support that we need to keep the group messaging work item in the charter. From the Sensinode point of view I also agree that this is a mandatory feature to have for DTLS. We have requirements for this in lighting control, AMI and building automation. 

Do note that group key management will be out of scope for DICE at least in the near future, we expect group keys to be assigned out of band for our purposes. The current charter simply proposes to define how to use a group key (once everyone in the group has it) with the DTLS record layer. 

The group key management may be solved by the SOLACE activity, possibly by DICE in the future, or in some other standards work. We of course encourage people to start working on the problem regardless of which WG it will eventually belong to. 

Regards,
Zach

On Jul 8, 2013, at 6:10 PM, "Thanos, Daniel (GE Energy Management)" <[email-masked]> wrote:

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

-- 
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: Stephen Farrell <[email-masked]>
Date: Mon, 08 Jul 2013 21:49:01 +0100

Hi all,

A bit of advice as sponsoring AD:

On 07/08/2013 04:10 PM, Thanos, Daniel (GE Energy Management) wrote:
> Greetings All-
>
> My name is Daniel Thanos, I work for GE Grid Automation. It has been
> brought to my attention that multicast security maybe dropped from
> the DTLS charter for IoT. I would like to voice my support for
> keeping multicast security in the charter. I am working in the area
> of Distributed Automation for Smart Gird and in next generation
> communications/security and there will be a need to for
> multicast/group key management because of the nature of some
> automation protocols that we want to move into these network
> environments. Is there way to keep this in the charter? GE together
> with Philips is will willing to help lead this work.

And then...

On 07/08/2013 07:37 PM, Zach Shelby wrote:
> Do note that group key management will be out of scope for DICE at
> least in the near future, we expect group keys to be assigned out of
> band for our purposes. The current charter simply proposes to define
> how to use a group key (once everyone in the group has it) with the
> DTLS record layer.

So this is the kind of thing that you (the proponents of DICE) need
to be very careful about. It does have the potential to wreck your
BoF in Berlin.

Its very easy to read the current charter proposal as including
development of new key management for DTLS. Doing that work would
be a large undertaking and would need significant thought as it'd
perhaps be applicable in a much wider range of environments (e.g.
rtcweb) so its not clear that we'd have anything like the right
set of folks involved to go ahead and invent new key management.
We also have a TLS WG who maintain TLS, and who've had a clear
consensus that changes to the TLS state machine should be done in
that WG. I hope that's well enough understood.

Even if you assume that session keys are in place, and "just" want
to use those with a slightly tweaked record layer, that could
raise issues that might also have impact elsewhere, e.g. the
rtcweb WG will likely have a contentious debate about whether
both SDES and DTLS-SRTP ought be MTI in Berlin, and that could
be related, depending on how you describe what you folks want to do.
And of course, you'd be buying into doing a lot more security
analysis since you might be creating a new lucky-13 or similar
vulnerability. And there are >330 ciphersuites for TLS, many of
which might need to be considered.

The bottom line is that (D)TLS is an important protocol and the
more you want to do to it, the more you need to show you have the
right folks involved and have good potential solutions from which
a WG can start.

So all this needs to be done *very* carefully and you need to
explain the problem that you're attempting to address very clearly
and then show that there are potentially tractable solutions from
which a WG can start that won't have bad side-effects for other
uses of (D)TLS, and that won't get folks with other interests in
(D)TLS up in arms.

Personally, I'd not underestimate the potential here for a BoF
to go sideways - if you have to spend 45 minutes dealing with
folks who think you want to re-invent (D)TLS then this'll most
likely fail. And just saying "we don't want to reinvent TLS"
won't be enough, it'll have to be true as well - people at
the BoF won't be fooled and might be worried:-)

So, please, if you want to keep some MC aspect, please use the
time between now and Berlin to make sure you've a really really
crisp way of describing that, and what's in scope and what's
not in scope. And please also go talk to folks who're interested
in TLS more generally and see what they think.

Cheers,
S.

PS: I'd strongly recommend a read of this [1] for anyone who's
interested in the success of this activity, in particular section
1 of that RFC.

PPS: Apologies, I've still to read the drafts. But that's the kind
of thing you're up against;-) And yeah, I will have read 'em before
Berlin:-)

[1] http://tools.ietf.org/html/rfc5434

---

From: "Kumar, Sandeep" <[email-masked]>
Date: Tue, 9 Jul 2013 14:05:48 +0000

Given that there is a strong support (and need) from industry for a solution to the problem and no strong opposition to this within this group so far, the main thing to manage are expectations or rather misinterpretations of this work from outside this group. As Stefan suggested, explaining what is in scope and outside scope in a crisp format is the very first step.

My one-liner for the work item would be "Enabling secure group communication reusing DTLS Record layer".
To be precise,
In scope: Transport of group messages over the DTLS record layer with out-of-band group session keys
Out of scope: Changes to DTLS state-machine, Group Session Key Management.

Hope this helps in starting a discussion with folks outside this group to see what they think.

Kind regards
Sandeep
________________________________________
From: [email-masked] [[email-masked]] on behalf of Stephen Farrell [[email-masked]]
Sent: Monday, July 08, 2013 10:49 PM
To: Zach Shelby
Cc: Thanos, Daniel (GE Energy Management); [email-masked]
Subject: Re: [Dtls-iot] Mail regarding draft-keoh-tls-multicast-security        status

Hi all,

And then...

Cheers,
S.

________________________________
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.