Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 5 May 2014 17:45:38 -0400

Hi Marco,

The authors have made an update to the draft to address fully your good
question regarding how to handle the unicast responses to the multicast
response.  Specifically, please review the new section 4.5 and tell us
if you have any more questions:

http://tools.ietf.org/html/draft-keoh-dice-multicast-security-06#section
-4.5

4.5.  Unicast Responses to Multicast Messages

   In CoAP, responses to multicast messages are always sent back as

   unicast.  That is, the group members that receive a multicast message

   may individually decide to send (or suppress) a unicast response as

   described in Section 2.5 of [I-D.ietf-core-groupcomm].  The unicast

   responses to a DTLS-based multicast message may optionally be secure.

   Specifically, the unicast response may be sent back as a unicast DTLS

   as described in Section 9.1 of [I-D.ietf-core-coap].  This requires

   that a unicast DTLS handshake was previously initiated between the

   multicast message sender and listener.  In the extreme scenario, a

   multicast sender may attempt to initiate the unicast DTLS handshake

   with all or a subset of known listeners just before or just after it

   sends out the DTLS-based multicast message.  This may result in the

   multicast sender (i.e. unicast DTLS client) having to process unicast

   DTLS handshake messages from multiple multicast listeners (i.e.

   unicast DTLS servers) in a short period.

   Note: There is an obvious timing and processing load issue for the

   multicast sender in the scenario where it attempts to initiate the

   unicast DTLS handshakes with all/some of its known listeners just

   after it sends out the DTLS-based multicast message.  In this case,

   the processing load in the multicast sender (i.e. unicast DTLS

   client) is reduced somewhat by the fact that CoAP requires a back-off

   and randomization of the unicast response by the Leisure timer

   mechanism as described in Section 8.2 of [I-D.ietf-core-coap].

 

Best Regards,

Akbar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Kumar,
Sandeep
Sent: Wednesday, April 02, 2014 3:47 AM
To: Marco Tiloca; [email-masked]
Subject: Re: [Dtls-iot] Unicast responses in
draft-keoh-dice-multicast-security-05

Hi Marco

The draft only addresses the protection of multicast traffic. If unicast
responses are expected and if protection is required for such messages,
then existing unicast protection mechanisms based on DTLS as suggested
in draft-ietf-core-coap-18 should be used. Protection of all unicast
messages should be treated as would be done normally. 

Hope that answers your question.

Regards

Sandeep 

From: dtls-iot [mailto:[email-masked]] On Behalf Of Marco
Tiloca
Sent: Tuesday, April 01, 2014 6:35 PM
To: [email-masked]
Subject: [Dtls-iot] Unicast responses in
draft-keoh-dice-multicast-security-05

Dear all,

As to possible responses to multicast requests, Section 2.1 states that
they are sent back in unicast. Then, no further details are provided
about their protection.

Are such responses supposed to be protected through a "regular" DTLS
session, which must be (or has previously been) established between the
sender and listener?

Cheers,

Marco

 

________________________________

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: Marco Tiloca <[email-masked]>
Date: Tue, 6 May 2014 18:31:45 +0200

Hello Akbar,

Thanks for having considered my question. The new Section 4.5 looks fine to
me. Also, I have the two following comments.

1) In order to perform a DTLS handshake before/after sending a multicast
message, a sender node should be aware of the group membership, especially
what are the listener nodes currently present in the group. Of course, such
a group membership may change over time, upon new nodes joining the group.
However, Section 3.1 in the draft states that "Any device can in principle
decide to listen to any IPv6 multicast address. This also means
applications on the other devices do not know, or do not get notified, when
new listeners join the network.". Couldn't this be a problem for the
suggested approach?

2) An alternative approach to the one suggested in Section 4.5 may consist
in a listener node establishing a unicast DTLS session (i.e. starting a
DTLS handshake) with the sender node, upon receiving a multicast message
for the first time.

Best regards,
Marco

On 5 May 2014 23:45, Rahman, Akbar <[email-masked]> wrote:

> response.  Specifically, please review the new section 4.5 and tell us if
> you have any more questions:
>
>
>
>
>
>
> http://tools.ietf.org/html/draft-keoh-dice-multicast-security-06#section-4.5
>
>
>
> *From:* dtls-iot [mailto:[email-masked]] *On Behalf Of *Kumar,
> Sandeep
> *Sent:* Wednesday, April 02, 2014 3:47 AM
> *To:* Marco Tiloca; [email-masked]
> *Subject:* Re: [Dtls-iot] Unicast responses in
> then existing unicast protection mechanisms based on DTLS as suggested in
> draft-ietf-core-coap-18 should be used. Protection of all unicast messages
> should be treated as would be done normally.
>
>
>
> *From:* dtls-iot [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Marco Tiloca
> *Sent:* Tuesday, April 01, 2014 6:35 PM
> *To:* [email-masked]
> *Subject:* [Dtls-iot] Unicast responses in
> they are sent back in unicast. Then, no further details are provided about
> their protection.
>
>
>
> ------------------------------
>
> 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: "Rahman, Akbar" <[email-masked]>
Date: Tue, 6 May 2014 16:44:15 -0400

Hi Marco,

Thanks for reviewing the updated draft.  Also here is my feedback to your two new questions:

>1) In order to perform a DTLS handshake before/after sending a multicast message, a sender

> node should be aware of the group membership, especially what are the listener nodes currently

> present in the group. Of course, such a group membership may change over time, upon new nodes
>joining the group. However, Section 3.1 in the draft states that "Any device can in principle decide

>to listen to any IPv6 multicast address. This also means applications on the other devices do not

>know, or do not get notified, when new listeners join the network.". Couldn't this be a problem

>for the suggested approach?

Yes, in principle, any device can decide to listen for any IPv6 multicast address.  But in practice of course there are IPv6 multicast related protocols for routing/joining that dictate who can successfully listen for and receive an IPv6 multicast packet.  For example, unless a device uses a protocol like MLD to explicitly join a multicast group, the network will never route the multicast packets of interest to the sub-network of the device.  This is all explained at a high level in the I.D.groupcomm reference (http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.1 ) .

The other part of your question refers to how does the sender node know who is part of the group.  You are correct that it is very difficult to know precisely the membership of a group.  That is why we had the subtle reference to “known listeners”.  How you actually know the membership depends on the mix of protocols used (and is in fact it is not always possible to know all the members accurately).  But for CoAP group member discovery, there is  again guidance given in the I.D.groupcomm reference (specifically in http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.6 ).  We can make this point a bit more explicit in the next update of our I-D.

>2) An alternative approach to the one suggested in Section 4.5 may consist in a listener node establishing

> a unicast DTLS session (i.e. starting a DTLS handshake) with the sender node, upon receiving a multicast

> message for the first time.

Yes, good point!  We can add this to the I-D in our next update. 

Best Regards,

Akbar

From: Marco Tiloca [mailto:[email-masked]] 
Sent: Tuesday, May 06, 2014 12:32 PM
To: Rahman, Akbar
Cc: Kumar, Sandeep; [email-masked]
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hello Akbar,

Thanks for having considered my question. The new Section 4.5 looks fine to me. Also, I have the two following comments.

1) In order to perform a DTLS handshake before/after sending a multicast message, a sender node should be aware of the group membership, especially what are the listener nodes currently present in the group. Of course, such a group membership may change over time, upon new nodes joining the group. However, Section 3.1 in the draft states that "Any device can in principle decide to listen to any IPv6 multicast address. This also means applications on the other devices do not know, or do not get notified, when new listeners join the network.". Couldn't this be a problem for the suggested approach?

2) An alternative approach to the one suggested in Section 4.5 may consist in a listener node establishing a unicast DTLS session (i.e. starting a DTLS handshake) with the sender node, upon receiving a multicast message for the first time.

Best regards,

Marco

 

Hi Marco,

The authors have made an update to the draft to address fully your good question regarding how to handle the unicast responses to the multicast response.  Specifically, please review the new section 4.5 and tell us if you have any more questions:

 

Best Regards,

Akbar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Kumar, Sandeep
Sent: Wednesday, April 02, 2014 3:47 AM
To: Marco Tiloca; [email-masked]
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Marco

The draft only addresses the protection of multicast traffic. If unicast responses are expected and if protection is required for such messages, then existing unicast protection mechanisms based on DTLS as suggested in draft-ietf-core-coap-18 should be used. Protection of all unicast messages should be treated as would be done normally. 

Regards

Sandeep 

From: dtls-iot [mailto:[email-masked]] On Behalf Of Marco Tiloca
Sent: Tuesday, April 01, 2014 6:35 PM
To: [email-masked]
Subject: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Dear all,

As to possible responses to multicast requests, Section 2.1 states that they are sent back in unicast. Then, no further details are provided about their protection.

Are such responses supposed to be protected through a "regular" DTLS session, which must be (or has previously been) established between the sender and listener?

Cheers,

Marco

 

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: "Rahman, Akbar" <[email-masked]>
Date: Fri, 9 May 2014 15:40:10 -0400

Hi Marco,

We have updated the draft to capture your remaining comments below.  Please review and tell us if you have any other comments.

http://tools.ietf.org/html/draft-keoh-dice-multicast-security-07#section-4.5 

   multicast message sender and listener.

   Either the multicast message sender or listener may initiate the

   unicast DTLS handshake.  If the DTLS handshake was initiated by the

   multicast message sender, it requires that the sender be aware of the

   membership of the multicast group.  This can be accomplished, for

   example, as described in Section 2.6 of [I-D.ietf-core-coap].  If the

   listener initiated the DTLS handshake, it may have done so, for

   example, after receiving a multicast message for the first time.

   In the extreme scenario, a multicast sender may attempt to initiate

   the unicast DTLS handshake with all, or a subset of, known listeners

   just after it sends out the DTLS-based multicast message.  This may

   result in the multicast sender having to process unicast DTLS

   handshake messages from multiple multicast listeners in a short

   period.

 

Best Regards,

Akbar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Tuesday, May 06, 2014 4:44 PM
To: Marco Tiloca
Cc: Kumar, Sandeep; [email-masked]
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Marco,

 

 

 

Best Regards,

Akbar

Hello Akbar,

Best regards,

Marco

 

Hi Marco,

 

 

Best Regards,

Akbar

Hi Marco

Regards

Sandeep 

Dear all,

Cheers,

Marco

---

From: Marco Tiloca <[email-masked]>
Date: Mon, 12 May 2014 10:24:26 +0200

Hello Akbar,

The updated version looks really good to me.

Best regards,
Marco

On 9 May 2014 21:40, Rahman, Akbar <[email-masked]> wrote:

> Hi Marco,
>
>
>
>
>
> We have updated the draft to capture your remaining comments below.
> Please review and tell us if you have any other comments.
>
>
>
>
>
>
> *From:* dtls-iot [mailto:[email-masked]] *On Behalf Of *Rahman,
> Akbar
> *Sent:* Tuesday, May 06, 2014 4:44 PM
> *To:* Marco Tiloca
>
> *Cc:* Kumar, Sandeep; [email-masked]
> message, a sender
> Yes, in principle, any device can decide to listen for any IPv6 multicast
> address.  But in practice of course there are IPv6 multicast related
> protocols for routing/joining that dictate who can *successfully* listen
> for and receive an IPv6 multicast packet.  For example, unless a device
> uses a protocol like MLD to explicitly join a multicast group, the network
> will never route the multicast packets of interest to the sub-network of
> the device.  This is all explained at a high level in the I.D.groupcomm
> reference (
> http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.1 ) .
>
>
>
> The other part of your question refers to how does the sender node know
> who is part of the group.  You are correct that it is very difficult to
> know precisely the membership of a group.  That is why we had the subtle
> reference to “known listeners”.  How you actually know the membership
> depends on the mix of protocols used (and is in fact it is not always
> possible to know all the members accurately).  But for CoAP group member
> discovery, there is  again guidance given in the I.D.groupcomm reference
> (specifically in
> http://tools.ietf.org/html/draft-ietf-core-groupcomm-18#section-2.6 ).
> We can make this point a bit more explicit in the next update of our I-D.
>
>
>
>
>
>
>
> *From:* Marco Tiloca [mailto:[email-masked] <[email-masked]>]
> *Sent:* Tuesday, May 06, 2014 12:32 PM
> *To:* Rahman, Akbar
> *Cc:* Kumar, Sandeep; [email-masked]
> Thanks for having considered my question. The new Section 4.5 looks fine
> to me. Also, I have the two following comments.
>
>
>

---

From: "Dijk, Esko" <[email-masked]>
Date: Mon, 19 May 2014 16:01:39 +0000

Hi Akbar,

apologies for my late input! On the new text, two points (see below) may need some further discussion. Here we deviate from the spirit of core-coap-18, which may need to be pointed out in the text explicitly, if the deviation is considered acceptable.

1. Unsecured responses
“The unicast responses to a DTLS-based multicast message may optionally be secure”
-> Compare to section 9.1.2 of core-coap:
“This means the response to a DTLS secured request MUST always be DTLS
   secured using the same security session and epoch.  Any attempt to
   supply a NoSec response to a DTLS request simply does not match the
   request and (unless it does match an unrelated NoSec request)
   therefore MUST be rejected.“

It seems unsecured responses are not possible without altering the CoAP request/response matching rules.

2. Who initiates the handshake
“Either the multicast message sender or listener may initiate the
   unicast DTLS handshake. “
-> Compare to section 9.1.1 of core-coap:
“The endpoint acting as the CoAP client should also act as the DTLS
   client.  It should initiate a session to the server on the
   appropriate port.”

best regards,
Esko

From: dtls-iot [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Friday, May 09, 2014 21:40
To: Marco Tiloca
Cc: Kumar, Sandeep; [email-masked]
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Marco,

Best Regards,

Akbar

From: dtls-iot [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Tuesday, May 06, 2014 4:44 PM
To: Marco Tiloca
Cc: Kumar, Sandeep; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Marco,

Best Regards,

Akbar

From: Marco Tiloca [mailto:[email-masked]]
Sent: Tuesday, May 06, 2014 12:32 PM
To: Rahman, Akbar
Cc: Kumar, Sandeep; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hello Akbar,

Best regards,
Marco

On 5 May 2014 23:45, Rahman, Akbar <[email-masked]<mailto:[email-masked]>> wrote:
Hi Marco,

Best Regards,

Akbar

From: dtls-iot [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Kumar, Sandeep
Sent: Wednesday, April 02, 2014 3:47 AM
To: Marco Tiloca; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Marco

Regards
Sandeep

From: dtls-iot [mailto:[email-masked]] On Behalf Of Marco Tiloca
Sent: Tuesday, April 01, 2014 6:35 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Dear all,

Cheers,
Marco

---

From: "Rahman, Akbar" <[email-masked]>
Date: Mon, 19 May 2014 16:33:57 -0400

Hi Esko,

Thanks for the feedback.

> It seems unsecured responses are not possible without altering the CoAP request/response matching rules.

Yes, but as you know the current core-coap-18 text is obviously written for unicast DTLS request and response.  We are no longer dealing with that as we have multicast DTLS request, and potentially unicast DTLS response.  (That was the original value in the question asked by Marco).  But I do agree with your point that the base core-coap-18 operation would be affected, and tha  this change must be clearly captured.   And I guess http://tools.ietf.org/html/draft-keoh-dice-multicast-security-07#section-4.5 would be the normative update.  So we have to make the text clear.  Do you think we need to explain it better?

-> Compare to section 9.1.1 of core-coap: “The endpoint acting as the CoAP client should also act as the DTLS client.  It should initiate a session to the server on the appropriate port.”

Again, I understood that this was originally written from the point of view of a normal unicast CoAP request.  Meaning that a CoAP client would have initially performed a request (e.g. GET) and thus should be the one that decides if the GET should be secure or not.  Again this logic does not apply directly for the multicast case because the interactions are different.  So I agree that we need to explicitly state in draft-keoh-dice-multicast that we are deviating from the original core-coap-18 approach.

Best Regards,

Akbar

From: Dijk, Esko [mailto:[email-masked]] 
Sent: Monday, May 19, 2014 12:02 PM
To: Rahman, Akbar; Marco Tiloca
Cc: Kumar, Sandeep; [email-masked]
Subject: RE: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Akbar,

1. Unsecured responses

   appropriate port.”

best regards,

Esko

Hi Marco,

 

 

   period.

 

Best Regards,

Akbar

Hi Marco,

 

 

 

Best Regards,

Akbar

Hello Akbar,

Best regards,

Marco

 

Hi Marco,

 

 

Best Regards,

Akbar

Hi Marco

Regards

Sandeep 

Dear all,

Cheers,

Marco

---

From: "Dijk, Esko" <[email-masked]>
Date: Tue, 20 May 2014 12:28:56 +0000

Hi Akbar,

on point 1. there are two concerns that need to be addressed:

1A. responding unsecured after a secured request seems a violation of security principles and the ‘spirit’ of CoAP-18. E.g. the response could be tampered with. What we could do is to e.g. have a SHOULD requirement for secured response; which the exception case being a response that does not contain any critical/confidential information. Such as a “2.04 Changed” or “2.02 Deleted” response which does not contain any further payload. But even doing that there may be unintended security consequences, e.g. response spoofing or tampering.

1B. if standard CoAP matching rules are not followed, the new matching rules need to be defined. What complicates this is that a client doesn’t know a priori if the server would respond DTLS-secured or not. So it needs two methods of matching, one for secured responses and another for unsecured ones.

The above issues together seem quite serious.  Perhaps an alternative solution is better in which the group key is used to DTLS-protect the response. Or alternatively, a separate “receivers” security group could be created that allows each receiver to respond and the sender to read the response, but nodes outside the sender/receiver groups cannot access the messages thus exchanged.

On point 2. I agree.

Esko

From: Rahman, Akbar [mailto:[email-masked]]
Sent: Monday, May 19, 2014 22:34
To: Dijk, Esko
Cc: Kumar, Sandeep; [email-masked]; Marco Tiloca
Subject: RE: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Esko,

Thanks for the feedback.

Best Regards,

Akbar

Hi Akbar,

1. Unsecured responses

best regards,
Esko

Hi Marco,

Best Regards,

Akbar

Hi Marco,

Best Regards,

Akbar

Hello Akbar,

Best regards,
Marco

Best Regards,

Akbar

Hi Marco

Regards
Sandeep

Dear all,

Cheers,
Marco

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 20 May 2014 15:04:35 +0200

> 1B. if standard CoAP matching rules are not followed, the new matching rules need to be defined. What complicates this is that a client doesn’t know a priori if the server would respond DTLS-secure…

We have similar problems in other alternate-transports scenarios, where the response channel is not necessarily tightly bound to the request channel.
I would expect we will arrive at similar solutions here.

Grüße, Carsten

---

From: "Rahman, Akbar" <[email-masked]>
Date: Wed, 21 May 2014 10:20:18 -0400

Hi Esko,

I agree on your points 1A and 1B and will work with you off line to update the draft to capture these points.

I did have one important question though on your last point:

>The above issues together seem quite serious.  Perhaps an alternative solution is better in which the group key

> is used to DTLS-protect the response. Or alternatively, a separate “receivers” security group could be created

>that allows each receiver to respond and the sender to read the response, but nodes outside the 

>sender/receiver groups cannot access the messages thus exchanged.

Are  you proposing changing the current Groupcomm I-D model of strictly unicast responses to a multicast CoAP request?  Your suggestion above seems to imply changing the model to multicast responses?

Best Regards,

Akbar

From: Dijk, Esko [mailto:[email-masked]] 
Sent: Tuesday, May 20, 2014 8:29 AM
To: Rahman, Akbar
Cc: Kumar, Sandeep; [email-masked]; Marco Tiloca
Subject: RE: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Akbar,

On point 2. I agree.

Esko

Hi Esko,

Thanks for the feedback.

 

 

Best Regards,

Akbar

Hi Akbar,

1. Unsecured responses

   appropriate port.”

best regards,

Esko

Hi Marco,

 

 

   period.

 

Best Regards,

Akbar

Hi Marco,

 

 

 

Best Regards,

Akbar

Hello Akbar,

Best regards,

Marco

 

Hi Marco,

 

 

Best Regards,

Akbar

Hi Marco

Regards

Sandeep 

Dear all,

Cheers,

Marco

---

From: "Dijk, Esko" <[email-masked]>
Date: Thu, 22 May 2014 11:05:27 +0000

Ok, we're not alone then! First question for us is whether details of doing an unsecured response to a secured multicast request should be in scope of this draft, or to be left for other/future work? Any views on this are welcome (and meanwhile I'll work offline with Akbar to discuss next steps).

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, May 20, 2014 15:05
To: Dijk, Esko
Cc: Rahman, Akbar; Marco Tiloca; Kumar, Sandeep; [email-masked]
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

On 20 May 2014, at 14:28, Dijk, Esko <[email-masked]> wrote:

> 1B. if standard CoAP matching rules are not followed, the new matching rules need to be defined. What complicates this is that a client doesn't know a priori if the server would respond DTLS-secured or not. So it needs two methods of matching, one for secured responses and another for unsecured ones.

Grüße, Carsten

---

From: Michael StJohns <[email-masked]>
Date: Thu, 22 May 2014 09:46:30 -0400

On 5/22/2014 7:05 AM, Dijk, Esko wrote:
> Ok, we're not alone then! First question for us is whether details of doing an unsecured response to a secured multicast request should be in scope of this draft, or to be left for other/future work?
The first question still remains as to whether or not we should be 
attempting to secure multicast UDP or an application protocol running on 
UDP with a DTLS variant.  So far, the analysis has strongly suggested NO 
and that such security - if any - should be applied as part of the 
application layer and using asymmetric cryptography rather than TLS's 
symmetric (for records) cryptography.

EKR's comment at the mike at the last meeting is specific and on topic:

    - Eker - You should abandon DTLS record layer to support multicast
    [if you want to support source authentication].  Source
    authentication is really required for many IoT use cases.

You can't do control applications without source authentication, and the 
draft was a) written to apply to a control application, and b) does not 
supply source authentication in any meaningful way.

My continued belief is that the current 
draft-keoh-dice-multicast-security is not viable as a DICE submission in 
its current form, and that the protection of multicasted data is 
probably more appropriately done more at the application layer and 
tailored for specific applications needs (e.g. the representative 
application that was discussed with me is turn on and off lights).  Any 
DICE based solution needs to be of general applicability, have minimal 
constraints and actually supply non-trivial security.

>   Any views on this are welcome (and meanwhile I'll work offline with Akbar to discuss next steps).
>
> Esko
>
> _______________________________________________
> dtls-iot mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dtls-iot

---

From: Zach Shelby <[email-masked]>
Date: Thu, 22 May 2014 07:23:32 -0700

Your point is taken Michael, and I agree we now need to be exploring an application layer solution. We are still waiting for the authors to submit a straw-man of that approach. So until that time, this is the only draft folks can discuss.

What is currently being discussed with regards to how to respond to a multicast request is relevant regardless of how you secure the message. The scope question is valid either way.

Personally, I don't think we should allow an unsecured response to a secure request (even for alternative transports).

Zach

On May 22, 2014, at 4:46 PM, Michael StJohns <[email-masked]> wrote:

> The first question still remains as to whether or not we should be attempting to secure multicast UDP or an application protocol running on UDP with a DTLS variant.  So far, the analysis has strongly suggested NO and that such security - if any - should be applied as part of the application layer and using asymmetric cryptography rather than TLS's symmetric (for records) cryptography.
>
> - Eker - You should abandon DTLS record layer to support multicast [if you want to support source authentication].  Source authentication is really required for many IoT use cases.
> You can't do control applications without source authentication, and the draft was a) written to apply to a control application, and b) does not supply source authentication in any meaningful way.
>
> My continued belief is that the current draft-keoh-dice-multicast-security is not viable as a DICE submission in its current form, and that the protection of multicasted data is probably more appropriately done more at the application layer and tailored for specific applications needs (e.g. the representative application that was discussed with me is turn on and off lights).  Any DICE based solution needs to be of general applicability, have minimal constraints and actually supply non-trivial security.
>
>
>
>> From: Carsten Bormann [
>> mailto:[email-masked]
>> ]
>> On 20 May 2014, at 14:28, Dijk, Esko
>> <[email-masked]>
>>  wrote:
>>
>>

Zach Shelby
Director of Technology
ARM Internet of Things BU
www.arm.com
mobile: +1 (408) 203-9434
Skype: zdshelby
LinkedIn: fi.linkedin.com/in/zachshelby/

-- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium.  Thank you.

ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2557590
ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No:  2548782

---

From: Dorothy Gellert <[email-masked]>
Date: Thu, 22 May 2014 18:15:47 +0000

Hi All-

It appears that we are still struggling with the issues raised with the multicast draft at the last IETF meeting.
In order to move forward at the next WG meeting, can we please document these issues in the  draft so we know when its appropriate to apply this solution.

Specifically,  I suggest we take out references to control systems in the Abstract, as this seems to be the sticking point.    From the email below its suggested that the authors agreed on the use case to turn on and off lights, rather than lighting control in general.   Can we update the draft to reflect this agreement?

Thanks,
Dorothy Gellert
Silver Spring Networks
E [email-masked]<mailto:[email-masked]>
O +1 650 839 4378
C +1 650 556-5994
[Description: Description: Description: Description: cid:[email-masked]]

From: Mike St Johns <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 22, 2014 at 6:46 AM
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Esko

-----Original Message-----
From: Carsten Bormann [mailto:[email-masked]]
Sent: Tuesday, May 20, 2014 15:05
To: Dijk, Esko
Cc: Rahman, Akbar; Marco Tiloca; Kumar, Sandeep; [email-masked]<mailto:[email-masked]>
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

On 20 May 2014, at 14:28, Dijk, Esko <[email-masked]><mailto:[email-masked]> wrote:

Grüße, Carsten

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

---

From: "Dijk, Esko" <[email-masked]>
Date: Fri, 23 May 2014 09:23:08 +0000

> Are  you proposing changing the current Groupcomm I-D model of strictly unicast responses to a multicast CoAP request?  Your suggestion above seems to imply changing the model to multicast response…
No, that was not intended – I’m not even sure if this option is realistic. Let’s stick for now with unicast response or no-response.

Esko

From: dtls-iot [mailto:[email-masked]] On Behalf Of Rahman, Akbar
Sent: Wednesday, May 21, 2014 16:20
To: Dijk, Esko
Cc: Marco Tiloca; Kumar, Sandeep; [email-masked]
Subject: Re: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Esko,

Best Regards,

Akbar

From: Dijk, Esko [mailto:[email-masked]]
Sent: Tuesday, May 20, 2014 8:29 AM
To: Rahman, Akbar
Cc: Kumar, Sandeep; [email-masked]<mailto:[email-masked]>; Marco Tiloca
Subject: RE: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Akbar,

On point 2. I agree.

Esko

From: Rahman, Akbar [mailto:[email-masked]]
Sent: Monday, May 19, 2014 22:34
To: Dijk, Esko
Cc: Kumar, Sandeep; [email-masked]<mailto:[email-masked]>; Marco Tiloca
Subject: RE: [Dtls-iot] Unicast responses in draft-keoh-dice-multicast-security-05

Hi Esko,

Thanks for the feedback.

Best Regards,

Akbar

Hi Akbar,

1. Unsecured responses

best regards,
Esko

Hi Marco,

Best Regards,

Akbar

Hi Marco,

Best Regards,

Akbar

Hello Akbar,

Best regards,
Marco

Best Regards,

Akbar

Hi Marco

Regards
Sandeep

Dear all,

Cheers,
Marco

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 23 May 2014 13:06:17 +0200

> Personally, I don't think we should allow an unsecured response to a secure request (even for alternative transports).

Right.  What we would need to make this work is either

1) A way to send a unicast response within the same channel (security envelope) that transported the multicast message.  E.g. if the multicast channel is based on a group key, the security for the response would be based on the group key as well (with the same limitations as to which security objectives can be achieved).

2) a way to bind the unicast channel used by the response to the multicast channel used for the request in such a way that the security objectives can be maintained.  This binding can be done
2a) as a part of the channel setup
2b) mediated through some CoAP-level mechanism
2c) both.
And this setup can be done:
2α) proactively (as part of the membership protocol)
2β) reactively (when a response needs to be sent)

Grüße, Carsten