Subject: [core] tiloca-core-muticast-oscoap-4

From: peter van der Stok <[email-masked]>
Date: Tue, 06 Feb 2018 12:04:36 +0100

Hi authors,

Many thanks for this very useful document. Below some comments. These 
are mainly restricted to document structure, relation to other 
documents, and new concepts and terminology. I hope they are 
sufficiently clear and help improving the text.

Peter

Abstract:
I did not see text that validates the phrase:
“All security requirements fulfilled by OSCORE are
maintained for multicast OSCORE request messages and related OSCORE
response messages.”
I did see: this document specifies the parameter values for OSCORE 
messages applied to group communication.
Why is source authentication more important (mentioned separately) than 
all other security aspects of OCORE?

Introduction:
Benefit from a group communication model: A possible group communication 
model is the use of unicast for all individual destinations; I don’t see 
how this increases efficiency. May-be you mean: leveraging the broadcast 
model of the underlying communication medium?
Across intermediary nodes -> possibly involving intermediary nodes.
The phrase: “To this end, …. protected message” is funny. I did not know 
that you could protect messages by including payload (something went 
wrong in this phrase).
Remove: “while fulfilling the same security requirements”. My 
suggestion: end-to-end security is assured by using the same security 
technology as for OSCORE.
The OSCORE draft mentions:
“providing end-to-end encryption, integrity, replay protection, and
secure the binding of response to request”. It does not mention source 
authentication explicitly. So, why is multicast-oscoap different?

Section 1.1
Multicaster: Is M <= N? sub-question is: are the destinations always all 
group members and is the source also a destination? May be you should 
refer to section 2.2 which provides a better explanation.
Endpoint ID: why this exclusion of pure listeners? It complicates the 
protocol.
Remove: “That is, …. same time”. Does not clarify uniqueness.

Section 2.
I do understand the purpose of section 2.2, but not of section 2.1. As 
far as I understand the Group Manager is essential for secure group 
communication as specified here; No GM means no group communication (is 
that correct?) In that case I would suggest two other subsections. 
Section 2.1a Requirements on group manager, section 2.1b, Protocol 
characteristics.

Multicast communication topology: remove the lighting use case, and 
refer to appendix.
Multicast group size: is this the number of members? The fact that a 
member may be listener as well as multicaster is another aspect and not 
relevant to size. The numbers are interesting to guide implementers.

Establishment and Management of Security context: I recommend to mention 
relation to OSCORE security contexts. Actually, the text seems to 
discuss requirements on the GM. GM specification is out of scope but not 
any GM design can be used with oscoap-multicast.

Multicast data security Cipher suite: GM requirement??

Backward security: GM requirement? Actually, this poses the question of 
ordering of messages from different sources; Is there a total ordering 
of messages or only a partial source order? (I see this is explained in 
section 2.2) May be a forward reference?

Forward security: GM requirement?.

Section 2.2 security Objectives
Bullet 2; remove “In fact, …plaintext” ; does not add much
Bullet 3: shall be authenticated with respect to two sources (sender and 
group) (simultaneously?)

Section 3;
Suggestion: Each endpoint stores extensions of the Oscore context. I 
seem to read that the Contexts used for group communication are 
extensions to the one specified for OSCORE. If that is true, use 
different names or use extension of .
Common context -> group context? In OSCORE the common context is defined 
as common between send and receiver, not common to the group.
Point 1, bullet 2: “ … once the security context is established”: do you 
mean the common context?
Point 2, The phrase “In practice,  … OSCORE messages” is difficult to 
understand (at least I see multiple explanations)
Do you mean that SenderID is equal to its endpointID received at 
joining?
It would be nice to give tables with additions to OSCORE security 
context for Sender Context, Recipient Context and Common (group) 
context; Now one has to search for them in the text.
Point 3 Is Recipient Id also equal to endpointID. The text about 
Recipient context creation is unclear. Is the creation done by the 
Recipient endpoint? How are the contexts shared? Who does the sharing? 
Or do you mean that they are copied over at reception?
Sender pubic key is extracted from Sender context (stored in GM, or sent 
over with message?) or from a trusted key repository? This paragraph is 
not very clear to me. Parts of the text are good candidates for a GM 
requirements section. See my comments about appendix C.

Section 3.1 Remove: “such a risk… office buildings. Nevertheless”. The 
fun with drones provided by Dutch universities, proves these assumptions 
to be futile.

Distribution of master key is another GM requirement.

Section 4 bullit 1: The phrase “set to the SenderId of the endpoint” 
creates the impression that an endpoint has multiple IDs. Probably, you 
mean:  the SenderId of the Context is set to the ID of the endpoint (or 
similar much better text)
Bullit 2 star 1: Is the group’s Security Context equal to the Common  
context?

Figure 1 differs from figure 7 in OSCORE draft

Section 5; Suggestion: In case of malformed messages a “listening only” 
receiver endpoint silently rejects the message and sends no error 
message; all other receivers return an error message x.xx.

Section 5.1
The document uses two terms: multicaster endpoint and sender endpoint; I 
assume they are equal concepts; If yes, choose one, if no, explain 
difference.

Point 1; stores where? Find where?

Section 5.2 point 2; It is not clear how a new Recipient context is 
created; That is probably due to the vague duties of the GM.

Section 6; I think that synchronizing sequence numbers is part of the 
standard and should be specified as requirement on the GM.

Section 7.1  Remove “for instance .. those roles” Refer to appendix A.

Section 7; Don’t you need some discussion on size of group to discuss 
security breach probabilities?

Appendix A
lighting control; here you refer to multicast group, which is sometimes 
correct. In the introduction you talk about group communication.
Switches but also sensors can control the state of the lights. Why is 
the backbone multicast enabled? Is that a MUST?
Events within a 200 ms interval are perceived as simultaneous by humans. 
Necessary in many configurations.

In Building control, intervals of seconds are sufficient.

Commissioning of LLN system; Interesting idea that multicast should be 
enabled on a subnetwork for discovery. However, that would be after 
enrollment of the devices? I think the use case needs a bit more 
thought.

Emergency multicast; Also interesting, but that needs a fault tolerant 
multicast algorithm, like MPL. for example.

Appendix C. I like this appendix, it provides the necessary 
understanding how things will work in practice. Please keep this 
appendix but also create a section with GM requirements, with the 
purpose of the requirements explained in the appendix. (this is a 
suggestion, don’t know if it will work actually)

C.1  bullit management keying material: depend -> depends

C.3 I think the utilization of ACE framework SHOULD be part of the 
standard. Too many options reduce the interoperability. Especially 
standards about the GM seem rather crucial to me.

Appendix D. Are the proposed options interoperable within a group? Also 
here I would advocate interoperable solutions only.

-- 
Peter van der Stok
vanderstok consultancy
mailto: [email-masked]
www: www.vanderstok.org
tel NL: +31(0)492474673     F: +33(0)966015248