Subject: [Dtls-iot] Further analysis of the problem space and security - flexibility - ease of use - cost considerations (Fwd: DTLS multicast security)

From: Rene Struik <[email-masked]>
Date: Fri, 03 Oct 2014 11:01:49 -0400

Hi Dorothy:

Apologies for responding late to this (I was away last week and only 
slowly catching up on email).

I have gone through all the email regarding multicast security since Thu 
Sept 18, 2014, but saw lots of posturing, but not too much technical 
analysis of the problem space.

Main questions:
a) Is source authentication vs. group authentication technically 
feasible within typical use case constraints? What are these constraints?
Note: it is hard to find the codification of these constraints. {In 
other groups, one often uses ballparks of human perception time 
latencies of 250ms.}
b) Is source authentication vs. group authentication desirable?
Note: it seems this is certainly so for control messaging and perhaps 
for others (I have only seen the light presence sensor and broadcast of 
"switch on" example by Sandeep Kumar 
(http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), 
although Michael St. Johns gave a more futuristic "flock of drones" 
example 
(http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). 
The effect of messaging includes a state change on the recipient. I 
would expect some analysis of what to do in case of diagnosis (e.g., to 
find source of problem in lighting system or, in the case of drones, to 
figure out why that $2m drone suddenly crashed...).
c) Is source authentication expensive?
Note: the usual "certificates are expensive" argument has been touted by 
Sandeep Kumar 
(http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html).

The discussion I have seen focuses on static groups and "light bulb 
scenarios". This makes me wonder about this from a system perspective.

Further questions:
d) What happens if group membership changes?
Note: group membership changes should trigger a security event and an 
update of group keys (with some trade-off in granularity vs. security 
policy invariants). This was indirectly alluded to by Michael St. Johns 
(http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html).
e) How are group keys distributed in the first place?
Note: there has not been too much discussion on the mailing list as to 
how one sets up a secure channel in the first place, esp. in 
heterogeneous settings (e.g., not just a single vendor solution -- 
Philips Lighting only, say). There are possibilities to implement 
homogeneous trust domain solutions, such as HIMMO, but these (a) still 
require a secure channel for distribution of key shares; (b) are not 
designed with heterogeneous trust domain (multi-vendor operations) in mind.

I think it would behoove the group to have a clarify these questions, 
via a technical discussion, rather than political posturing.

Some related discussion prior to the IETF-90 meeting in Toronto (the 
"Tyranny of the lightswitch" email series triggered by Michael St. 
Johns) seems to suggest that the answer to question #a above may very 
well be affirmative (message #322 is by STMicro):
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00322.html
http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00337.html

Most posturing seems to be motivated by a desire to use symmetric-key 
only constructs. This may be fine, but does not necessarily address 
system level questions and the question how one can build systems that 
draw from multiple vendors this way.

Best regards, Rene

-------- Forwarded Message --------
Subject: 	[Dtls-iot] DTLS multicast security
Date: 	Thu, 18 Sep 2014 13:41:06 -0700
From: 	Dorothy Gellert <[email-masked]>
To: 	[email-masked]

Dear WG,

Last week our AD and the WG chairs, myself and Zach, met to discuss the progress of the DTLS multicast security Work Item.
it seems as though we have reach an impasse with regards to the issues raised on the mailing list with multicast security and DTLS.

If this is the consensus of the WG  we can progress the WG without this Work item and move forward with the other 2 work items, the dtls profile and practical issues around the DTLS handshake.

I’d like to request feedback from the WG on this plan.

Thanks,
Dorothy

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

---

From: Michael StJohns <[email-masked]>
Date: Fri, 03 Oct 2014 12:28:06 -0400

On 10/3/2014 11:01 AM, Rene Struik wrote:
> (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). The 
> effect of messaging includes a state change on the recipient. I would 
> expect some analysis of what to do in case of diagnosis (e.g., to find 
> source of problem in lighting system or, in the case of drones, to 

I was actually thinking more about something like a group of $300-$1000 
quad copters.  There are a lot of interesting YouTube videos about the 
emerging capabilities of flocking protocols.  I haven't looked at the 
control protocols they're using, but I would expect they use some form 
of emergent behavior based on local knowledge to do collision avoidance 
and group travel.

Mike

---

From: Dorothy Gellert <[email-masked]>
Date: Fri, 3 Oct 2014 11:25:13 -0700

Hi Rene,

Thanks for your comments.   When I read through your questions it seems what you referring to  in terms of system perspective is something along the lines of Best Practices section that
would address the questions you pose, such as diagnosis and group membership.   Key distribution was decided at the BoF to be out of band, but can be described in a Best Practices section or document. 

So far we have generated rough consensus around coap application based group use cases that require confidentiality only.   This is our problem statement we agreed we needed at the last IETF meeting. 
I also believe we have made the case that theses groups are “small” such that they can be enforced by the protocol.

We have a lighting use case and desire for another use case.  We need more discussion around that. 
Also from my discussions with my co -chair and AD, a discussion around cipher suites should be considered, given TLS 1.3  has specified AEAD cipher suites. 

Can you get behind this way forward for the next meeting?

Thanks,
Dorothy

In light of the 
On Oct 3, 2014, at 8:01 AM, Rene Struik <[email-masked]> wrote:

> Hi Dorothy:
> 
> Apologies for responding late to this (I was away last week and only slowly catching up on email).
> 
> I have gone through all the email regarding multicast security since Thu Sept 18, 2014, but saw lots of posturing, but not too much technical analysis of the problem space.
> 
> Main questions:
> a) Is source authentication vs. group authentication technically feasible within typical use case constraints? What are these constraints?
> Note: it is hard to find the codification of these constraints. {In other groups, one often uses ballparks of human perception time latencies of 250ms.}
> Note: it seems this is certainly so for control messaging and perhaps for others (I have only seen the light presence sensor and broadcast of "switch on" example by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), although Michael St. Johns gave a more futuristic "flock of drones" example (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00388.html)). The effect of messaging includes a state change on the recipient. I would expect some analysis of what to do in case of diagnosis (e.g., to find source of problem in lighting system or, in the case of drones, to figure out why that $2m drone suddenly crashed...). 
> Note: the usual "certificates are expensive" argument has been touted by Sandeep Kumar (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00378.html).
> 
> The discussion I have seen focuses on static groups and "light bulb scenarios". This makes me wonder about this from a system perspective.
> 
> Further questions:
> Note: group membership changes should trigger a security event and an update of group keys (with some trade-off in granularity vs. security policy invariants). This was indirectly alluded to by Michael St. Johns (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00379.html).
> Note: there has not been too much discussion on the mailing list as to how one sets up a secure channel in the first place, esp. in heterogeneous settings (e.g., not just a single vendor solution -- Philips Lighting only, say). There are possibilities to implement homogeneous trust domain solutions, such as HIMMO, but these (a) still require a secure channel for distribution of key shares; (b) are not designed with heterogeneous trust domain (multi-vendor operations) in mind.
> 
> I think it would behoove the group to have a clarify these questions, via a technical discussion, rather than political posturing.
> 
> Some related discussion prior to the IETF-90 meeting in Toronto (the "Tyranny of the lightswitch" email series triggered by Michael St. Johns) seems to suggest that the answer to question #a above may very well be affirmative (message #322 is by STMicro):
> Most posturing seems to be motivated by a desire to use symmetric-key only constructs. This may be fine, but does not necessarily address system level questions and the question how one can build systems that draw from multiple vendors this way.
> 
> Best regards, Rene
>

---

From: Rene Struik <[email-masked]>
Date: Fri, 03 Oct 2014 14:53:06 -0400

Hi Dorothy:

Most of the posturing seems to have been triggered not so much by 
technical arguments as to merits of source authentication vs. group 
authentication, but by some parties simply not wishing to risk having to 
implement public key functionality.

My email suggests that this posturing may be short-sighted and seemingly 
incompatible with the ultimate reason to even do standardization: 
facilitating deployments of systems with components from multiple 
vendors. In the end, one should be interested in having tools to build 
secure systems, not in Pyrrhus victories.

I know that some people opted for option "A" on the email list last 
week, but those preferences seemed to lack technical justification 
(anything else was just moved, again, to another group -- ACE?). As 
such, I find this approach a poor man's justification the IETF unworthy.

I think bringing technical merit discussion back on the table makes 
sense. We can roll up our sleeves and do some technical work or make 
this into a voting machinery (which I think IETF portends not to be). 
Even if one just wishes to stick with poor man's solutions, it would be 
good to finally get technical requirements on the table (e.g., re time 
latency, etc.), which has all been severely lacking so far.

Just ask yourself: why does it take 8 weeks of absolute silence since 
IETF-90 to suddenly get a flurry of posturing emails when multicast is 
mentioned by you in an email, with no technical arguments exchanged to 
justify option A? This may be a way to partition a problem, but has 
little to do with looking for a long-term viable technical mechanism for 
multicast.

BTW - here are my perspectives on the questions I posed:
a) Is source authentication vs. group authentication technically 
feasible within typical use case constraints? *YES, feasible**(without 
even the need to sign every message, so hybrid symmetric/public key 
approach possible). See also some emails of July 2014.* What are these 
constraints?*Let us stick with 250 ms time latency, failing further 
concise problem statements.*
b) Is source authentication vs. group authentication desirable? *Yes, 
for control messages. Just implement accross the board, to preclude 
feature creep of group authentication (which will happen - IETF cannot 
prevent people misusing constructs, so simply do not provide them).*
c) Is source authentication expensive? *No. See technical data points, 
Hannes Tschofenig's ARM speaker organized webcast, certs in consumer 
space virtually for free, etc.*
d) What happens if group membership changes? *Change of group membership 
requires a point to point secure channel update, thereby source 
authentication.*
e) How are group keys distributed in the first place? *Heterogeneous 
deployments, also in the lighting arena, require a heterogeneous 
lifecycle model, which is scalable with public-key technology. If one 
needs this anyway (why standardize otherwise, instead of having 
companies all do their own thing?), one could use the primitive also for 
source authentication in multi-cast setting.*

Rene

On 10/3/2014 2:25 PM, Dorothy Gellert wrote:
> Hi Rene,
>
> Thanks for your comments.   When I read through your questions it 
> seems what you referring to  in terms of system perspective is 
> something along the lines of Best Practices section that
> would address the questions you pose, such as diagnosis and group 
> membership.   Key distribution was decided at the BoF to be out of 
> band, but can be described in a Best Practices section or document.
>
> So far we have generated rough consensus around coap application based 
> group use cases that require confidentiality only.   This is our 
> problem statement we agreed we needed at the last IETF meeting.
> I also believe we have made the case that theses groups are “small” 
> such that they can be enforced by the protocol.
>
> Also from my discussions with my co -chair and AD, a discussion around 
> cipher suites should be considered, given TLS 1.3  has specified AEAD 
> cipher suites.
>
> On Oct 3, 2014, at 8:01 AM, Rene Struik <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>> Hi Dorothy:
>>
>> I have gone through all the email regarding multicast security since 
>> Thu Sept 18, 2014, but saw lots of posturing, but not too much 
>> technical analysis of the problem space.
>>
>> Main questions:
>> for others (I have only seen the light presence sensor and broadcast 
>> of "switch on" example by Sandeep Kumar 
>> (http://www.ietf.org/mail-archive/web/dtls-iot/current/msg00387.html), although 
>> Michael St. Johns gave a more futuristic "flock of drones" example 
>> would expect some analysis of what to do in case of diagnosis (e.g., 
>> to find source of problem in lighting system or, in the case of 
>> drones, to figure out why that $2m drone suddenly crashed...).
>> Note: the usual "certificates are expensive" argument has been touted 
>> by Sandeep Kumar 
>> Note: there has not been too much discussion on the mailing list as 
>> to how one sets up a secure channel in the first place, esp. in 
>> homogeneous trust domain solutions, such as HIMMO, but these (a) 
>> still require a secure channel for distribution of key shares; (b) 
>> are not designed with heterogeneous trust domain (multi-vendor 
>> operations) in mind.
>>
>> system level questions and the question how one can build systems 
>> that draw from multiple vendors this way.
>>
>> Best regards, Rene
>>
>> [email-masked] <mailto:[email-masked]>

-- 
email: [email-masked] | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 690-7363

---

From: Michael StJohns <[email-masked]>
Date: Fri, 03 Oct 2014 15:01:06 -0400

On 10/3/2014 2:25 PM, Dorothy Gellert wrote:
> group use cases that require confidentiality only. 

That's not exactly correct.  What I think we got was consensus that 
symmetric key multicast control wasn't going to fly and that symmetric 
key multicast confidentiality might be useful.  However, at this point 
the only use case described in draft-keoh... - lighting - doesn't 
actually require confidentiality.  So we're still a solution in search 
of a problem.

Mike

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 3 Oct 2014 21:29:15 +0200

On 03 Oct 2014, at 21:01, Michael StJohns <[email-masked]> wrote:

> What I think we got was consensus that symmetric key multicast control wasn't going to fly and that symmetric key multicast confidentiality might be useful.

Control is not a security service.
I don’t think there is consensus that group authentication is not useful.
In any case, it is hard to do confidentiality without some form of authentication.

I live in a world where the loudly stated arguments about group authentication being dangerous and asymmetric crypto being “cheap" just don’t apply.  Apparently, I have been unable to show some of you this world.  I just spent another two days in a workshop on systems and products where this is so patently obvious that words escape me.  So I don’t think we can have consensus between the IoT security view and the loudly stated military/banking security view here.

draft-mglt-dice-ipsec-for-application-payload-00 demonstrates that existing IETF standards track protocols suffice to solve the problem at hand, except maybe for a lack of optimization.  So maybe this is where those interested in solving this problem need to continue their work.

Grüße, Carsten

---

From: Dorothy Gellert <[email-masked]>
Date: Fri, 3 Oct 2014 12:39:56 -0700

Hi Rene-

As a co-chair I brought up the multicast security work item in an attempt find a way to move the item forward or to remove it.   There was support among the vocal members of the list to restrict the work item to restrict to confidentiality only, 
in light of the technical arguments made on the list.   I don’t want to keep re-hashing old arguments especially if they don’t promote a way forward.

You comments on system perspective are valid, and to propose a way forward I suggested a best practices consideration, as multicast security will be used with application protocols not specified by this group (coap).

I’m glad to see you answer the questions you proposed…. it seems you have a solution in mind.   I believe it would be helpful to put that idea into a draft that the WG can evaluate it in entirety. 

Thanks,
Dorothy

On Oct 3, 2014, at 11:53 AM, Rene Struik <[email-masked]> wrote:

> Hi Dorothy:
> 
> Most of the posturing seems to have been triggered not so much by technical arguments as to merits of source authentication vs. group authentication, but by some parties simply not wishing to risk having to implement public key functionality.
> 
> My email suggests that this posturing may be short-sighted and seemingly incompatible with the ultimate reason to even do standardization: facilitating deployments of systems with components from multiple vendors. In the end, one should be interested in having tools to build secure systems, not in Pyrrhus victories.
> 
> I know that some people opted for option "A" on the email list last week, but those preferences seemed to lack technical justification (anything else was just moved, again, to another group -- ACE?). As such, I find this approach a poor man's justification the IETF unworthy.
> 
> I think bringing technical merit discussion back on the table makes sense. We can roll up our sleeves and do some technical work or make this into a voting machinery (which I think IETF portends not to be). Even if one just wishes to stick with poor man's solutions, it would be good to finally get technical requirements on the table (e.g., re time latency, etc.), which has all been severely lacking so far. 
> 
> Just ask yourself: why does it take 8 weeks of absolute silence since IETF-90 to suddenly get a flurry of posturing emails when multicast is mentioned by you in an email, with no technical arguments exchanged to justify option A? This may be a way to partition a problem, but has little to do with looking for a long-term viable technical mechanism for multicast.I men
> a) Is source authentication vs. group authentication technically feasible within typical use case constraints? YES, feasible (without even the need to sign every message, so hybrid symmetric/public key approach possible). See also some emails of July 2014. What are these constraints? Let us stick with 250 ms time latency, failing further concise problem statements.
> b) Is source authentication vs. group authentication desirable? Yes, for control messages. Just implement accross the board, to preclude feature creep of group authentication (which will happen - IETF cannot prevent people misusing constructs, so simply do not provide them).
> c) Is source authentication expensive? No. See technical data points, Hannes Tschofenig's ARM speaker organized webcast, certs in consumer space virtually for free, etc.
> d) What happens if group membership changes? Change of group membership requires a point to point secure channel update, thereby source authentication.
> e) How are group keys distributed in the first place? Heterogeneous deployments, also in the lighting arena, require a heterogeneous lifecycle model, which is scalable with public-key technology. If one needs this anyway (why standardize otherwise, instead of having companies all do their own thing?), one could use the primitive also for source authentication in multi-cast setting.
> 
> Rene
>