[core] Fwd: [Ace] review oscore-groupcomm-2

[Peter van der Stok <[e-mail]>]

Hi authors,

Thanks for this useful document. 

I have no comments on sections 3 and 4 that read rather easily. 

Some comments on the other sections follow below: 

Section 1.1 

Introduce group request (GR)-message and response message in relation to
GR-client and GR-server to clarify text in section 2. To be used
consistently throughout the text. 

End page 3. The phrase on the use of DTLS seems a bit far-fetched; Do
you mean that multiple DTLS sessions are started for each group request
sent by a client? 

Group ID: s/a same Group Manager/a given Group Manager/ 

End section 1.1; remove: "by a different group member or by a
non-group-member" This only excludes itself. 

Section 2 

Where does the endpoint store all these contexts? I assume local storage
is used. 

Text substitution suggestions: 

s/Each endpoint in the group stores:/Each endpoint in a group makes use
of:/ 

s/endpoints in the group/endpoints in a given group/ 

s/The ID Context parameter stores the group ID/The ID Context parameter
contains the group ID/ 

The Sender context description is confusing. I understood that both a
client when sending a group request, and a receiver when sending a
response message use the sender context for sending the message. The
text seems to suggest that only a group request need a sender context
and not the response message. 

If the Sender context applies only to group request messages, the term
request context is more appropriate and distinguishes from the sender
context in OSCORE 

Same confusion about the recipient context; the text seems to exclude
that a group request client also needs a recipient context. 

Table 1:  why "each" Recipient context and not "each" sender context? 

Public key of the associated other endpoint: is this the group request
client endpoint or any endpoint sending to this recipient? 

Section 2.1:  should the section not refer to oscoap-joining draft in
ACE? 

Section 3 'kid' parameter value; Does this only apply to response
messages sent by group request servers? 

Section 5; I don't think that I understand the problem. One of the
conditions is that a client which is not part of a group cannot decrypt
the group messages, and a client that has left the group cannot decrypt
the group messages either. That constitutes already a pretty firm
synchronization. My assumption was that this would be effectuated by
distributing new master secret every time the group changes. In Appendix
C, you suggest the epoch in the GID (Chaging the epoch, the GID may
remain constant over group changes). My recommendation is to make the
epoch compulsory for synchronization purposes. 

During membership of a group, a GR-client can consecutively number its
messages starting at zero every time a new epoch is started (with a new
master secret as specified in section 2.1). See also remark on A.2. 

Section 6, 

what is the relation of section 6 with with oscoap-joining. Is
oscoap-joining required to validate all the requirements of section 6? 

Methods to handle loss of synchronization are not responsibility of GM
but responsibility of the sender of group request messages. No total
ordering on all messages is required, only partial ordering on the
messages of a given sender. I assume that the ordering of epochs is done
by GM. 

Trusted key repository: Also when the group manager makes use of an
additional secure storage device, it remains responsible for the key
repository. 

Acting as a network router is out of scope IMO. RFCs exist to create and
route group messages and it is immaterial which devices host the routing
agents. This is also a subject of appendix D; same remark applies there
as well. 

Autonomously and locally enforcing… ; what is the difference with bullet
2  of section 6? 

7.1 I don't understand the remark that all group members are trusted.
What does that mean? IMU, They have been authorized to join a group and
are trusted per definition. 

7.2 Case A and Case B refer to cases in OSCORE draft? 

7.3 Does it not need an explanation how one sender belonging to two
groups with the same GID can be distinguished by a receiver that is
member of these two groups as well? The text at the end of appendix C is
not very convincing. 

A.1 bullet 2; remove: "e.g. by grouping lights….."  (it is unknown how
large groups in one room can be, leave alone a floor) 

A.1 Establishments an management of security contexts: I hope that a
general key management scheme is not necessary to provide the GM with a
protocol to distribute new master secrets for the next group epoch. 

A.2 

Source Authentication, s/ensure/verify/ 

Message Integrity, s/ensure/verify/ 

Message ordering: Messages should be given a sequence number by the
sender, a new coap option could be defined. Total ordering of the
messages in a Group is not required. 

Appendix C: Could this text (or a variant) not become normative text to
provide simple source ordering. 

Appendix D: first three paragraphs double with Appendix A, just
differently formulated. Suggest to remove or better review separation
with appendix A. 

See router comment of section 6. 

Appendix D.1 is very informative but provides many choices. Oscoap join
should specify the choices. According to me much of the text of Appendix
D.1 should go to oscoap-join to motivate the choices made for oscoap
join. 

Appendix D.2. My suggestion is to make the GM the key repository, or
connect a key repository to it, that needs to be accessed through the
GM. 

Appendix D3. Should this not be normative text in oscoap-join? 

Appendix E. A relation between message freshness and message ordering is
suggested that I do not understand. When a sender sends only one message
ever, the ordering is assured, but freshness is not guaranteed on
reception. 

Suppose only ordering is guaranteed with sequence numbers in the
message; Losing messages can be detected. A procedure to receive lost
messages is indeed necessary. But this involves storage of messages at
the sender (how many?), and possibly re-encrypting to guarantee
freshness when they are repeated on loss detection. Hope this helps.

Greetings,

peter 
-- 
Peter van der Stok
vanderstok consultancy
mailto: [e-mail], [e-mail]
www: www.vanderstok.org [1]
tel NL: [phone]     F: [phone] 
_______________________________________________
Ace mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/ace 

Links:
------
[1] http://www.vanderstok.org