Subject: [COSE] Review on draft-ietf-core-oscore-groupcomm-03

From: Jim Schaad <[email-masked]>
Date: Tue, 8 Jan 2019 22:59:49 -0800

So I did a quick run through on this document with the intention of starting
an implementation.  During this process I came across the following issues:

* There should be a note someplace in the document to the effect that if a
new group id is generated, then there must be no reliance on the kid for an
entity being the same.  This can only be done by looking at the signing
public key.   Also if an entity gets to the point of nearing a roll-over,
then the Group Manager could just assign a new kid rather than re-keying the
entire group.

* Section 4.1 - Given that the signature is no longer part of the option
value, something that is both good and bad, I am unsure that there is any
requirement for the 'CounterSignature0' bit to be part of the bit array.
According to the requirements, one can always assume that for a group
message the counter signature will always be appended to the encrypted text.

* Section 3.  I am not clear if the group ID should be part of the aad_array
or not.  If it does not need to be present then I think that some text as to
why it does not need to be covered would be appreciated.  I should note that
I don't think that it needs to be there but have not proven it to my
satisfaction yet.

* Section 5 - The text says that Observe is not defined for group setting.
I am not sure that this is a true statement.  RFC 7641 does not say anything
one way or another about doing observer for multicast.  The only issue that
I can see is the fact that the path may not always be setup correctly if
going through a proxy, but for local network without a proxy I don't see any
reason why it should not work.

* Section 5.1 - I am unclear of why you are looking at talking about
re-transmission in this context.  This needs to be clarified.

* Section 6. - The fact that they are non-confirmable does not preclude
acknowledgement even in a group situation.  It may not be advised in general
but it is allowed.

* Section 6. - Note that responses can be confirmable even if the request is
not.

* Section 6.1 - You are missing the signature step here.

* Section 6.2 - I believe that there should be the ability to decouple the
processing of a response from the query back to the GM.  Specifically, if
you get a new kid for the group id, one should be able to ignore the current
message and start an async request for the new keying information on that
new sender.  Forbidding this should be an application decision not general
purpose.  Perhaps this should also include a note about the fact that a
server might observer the GM in order to get these new kids in a timely
manner.

*