Re: [core] 🔔 WG Call for Adoption on draft-tiloca-core-multicast-oscoap

[Marco Tiloca <[e-mail]>]

Hello Esko,

Thanks for your support and comments, we have considered them when
producing the latest version of the draft [1].

Please, find in line some answers to your comments.

Best,
/Marco

[1] https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-01


On 2017-12-04 14:35, Esko Dijk wrote:
>
> I also support the adoption of this draft as a work item for CoRE.
> Below are the results of a quick review, also.
>
>  
>
> Best regards
>
> Esko Dijk
>
>  
>
>  
>
> Overall comments – or work that the WG could take up next
>
> ·         Detailed example with message sizes would be useful. Since
> it’s important for multicast over 6lowpan performance that the IPv6
> packets stay small enough (one 802.15.4 frame). At this moment, I
> can’t judge that yet easily based on the draft.
>

[MT] We have now included detailed examples in Sections 3.1 (Request)
and Section 3.2 (Response).


> ·         Normally, for applications (e.g. Building automation and
> lighting) groups do need a stable and non-random group ID, that
> identifies the group over time even as changes occur, e.g. members
> added/removed. The “Gid” in the draft however changes. There could be
> some text added to explain how Gid is linked to a stable ID. E.g.,
> this could be configured by the Group Manager. The stable group ID is
> then not used over-the-wire for multicast OSCORE.
>

[MT] It is true that the Gid in this draft changes over time, especially
upon renewing the group keying material, and the Group Manager is the
only responsible for managing its value update. However, this Gid has to
be intended as the identifier of the OSCORE “security group”, including
as members the endpoints that share the same Common Security Context.

[MT] As you say, applications do rely on a stable and non-random group
ID, which is not used over-the-wire for group OSCORE, and instead
identifies an “application group” having as members the endpoints that
participate in a same group application. There is no relation between
this application-level group ID and the OSCORE Gid defined in this
draft. However, one may possibly map multiple “application groups” to
the same “security group”.

[MT] In order to clarify this point, we included also a definition of
“Group” and “Group ID” in Section 1.1.


> ·         There is normative text in the Appendices; it could be
> clarified what the status of this is. E.g. only normative if one
> chooses to implement the optional element described in the Appendix?I
> have a preference for avoiding normative text in the Appendices, but
> I’m curious to hear what others think.
>

[MT] We relaxed the text in Appendices to avoid normative references,
with the exception of a “NOT RECOMMENDED” in current Appendix F “No
Verification of Signatures”.

> ·         The text sometimes suggests that a secure group context is
> linked to one and only one multicast IP address. In practice, there
> may be more variety – e.g. one multicast IP address plus one or more
> unicast IP addresses to which the group message is subsequently
> delivered. E.g. repeat of the group message to members which did not
> get it yet. The proposed solution could be reviewed with that view in
> mind, that there may be multiple (multicast/unicast) IP destination
> addresses to which a group message will be sent. I did not do that
> yet; can do so in a future in-depth review.
>

[MT] Thanks, that’s a very good comment. We’ll think more on the
possible view you propose. It should be fine as long as a recipient is
able to retrieve the right group Security Context, by using the Gid.


>  
>
> Section 2.1
>
> Some things here are listed as out of scope, but they do come back
> later in the doc – such as forward security and backward security ,
> which are addressed I think – certainly not out of scope.
>

[MT] Group OSCORE does not ensure forward security and backward security
itself. Instead, they are entrusted to the specifying group rekeying
protocol enforced by the Group Manager. The specific rekeying protocol
if out of scope for Group OSCORE, which however recommends the use of
one able to ensure backward and forward security in the group.


>  
>
> Section 3
>
> " Gid MUST be random " -> seems to contradict Appendix B which uses an
> Epoch counter in the Gid.  Should it say “MUST have a random component” ?
>

[MT] Right, now fixed (in current Appendix C).


>  
>
> Appendices
>
>   * Appendix B, a concrete example instance is missing. E.g.
>     “w3fj90f0a_0042” or its bstr equivalent  (just guessing here to
>     the format)
>

[MT] We added an example, in current Appendix C.


>  *
>
>
>
>   * Appendix C, is this an example blueprint of how to do it – fully
>     optional to follow or not follow this?
>

[MT] We relaxed the text in current Appendix D, as for the time being it
is intended to be a guideline example.


>  *
>
>  
>
> Minor
>
>   * ligthing -> lighting
>   * enpoint  -> endpoint
>   * Pg 25 , [I-D.ietf-ace-dtls-authorize] reference breaks across line
>     and as such becomes non-searchable in the browser. And I like
>     these refs to be searchable 😉
>
>  
>
>  
>
>  
>
>  
>
>  
>
> *From:* core [mailto:[e-mail]] *On Behalf Of *Jaime Jiménez
> *Sent:* Thursday, November 23, 2017 17:59
> *To:* [e-mail] WG ([e-mail]) <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* [core] 🔔 WG Call for Adoption on
> draft-tiloca-core-multicast-oscoap
>
>  
>
> Dear all,
>
>  
>
> The draft on "Secure group communication for CoAP"
> ( draft-tiloca-core-multicast-oscoap
> <https://tools.ietf.org/html/draft-tiloca-core-multicast-oscoap/> )
> had in room consensus for adoption during IETF99 already, now we are
> clear to confirm it on the mailing list. 
>
>  
>
> Please reply to the list with your comments, including although
> not limited to whether or not you support adoption. Non-authors are
> especially encouraged to comment.
>
>  
>
> Target to end the WGA is 14th of December.
>
>  
>
> Ciao,
>
> - - Jaime Jiménez
>
>  
>
>
> ------------------------------------------------------------------------
> The information contained in this email may be confidential and/or
> 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 email 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 email.
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Marco Tiloca, PhD
Research Institutes of Sweden
RISE ICT/SICS
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)
Phone: [phone]
https://www.sics.se

The RISE institutes Innventia, SP and Swedish ICT
have merged in order to become a stronger research
and innovation partner for businesses and society.

SICS Swedish ICT AB, has now changed name to RISE SICS AB.