Re: [core] FW: Review on draft-ietf-core-oscore-groupcomm-03

[Marco Tiloca <[e-mail]>]

Hello Jim,

Thanks for the good comments!

Please, find our answers inline.

Best,
/Marco

On 1/9/19 4:10 PM, Jim Schaad wrote:
> Send to the right mailing list.
>
> -----Original Message-----
> From: Jim Schaad <[e-mail]> 
> Sent: Tuesday, January 8, 2019 11:00 PM
> To: '[e-mail]'
> <[e-mail]>
> Cc: 'cose' <[e-mail]>
> Subject: Review on draft-ietf-core-oscore-groupcomm-03
>
> 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.

<MT>
Agree, the 'kid' of an endpoint might change, for instance due to the
re-assigning procedure you mention. About that, We can extend Section
2.2 "Wrap-around of partial IVs" and describe a 'kid' renewal as an
alternative to the full group rekeying.

This would result in group members possibly retaining stale Recipient
Contexts. Applications can define policies to delete (long) unused
Recipient Contexts to save storage space.
</MT>

> * 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.

<MT>
It is true that the countersignature is always present for a group message.

We have been having more discussion on the usefulness of the signature
bit, and considering the possibility to remove its definition in the bit
array.
</MT>

> * 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.

<MT>
We are now re-evaluating if we should add the Context ID (which in Group
OSCORE contains the Group ID) to the external_aad, together with other
pieces of information that may require to be authenticated.

The Context ID can be added to the external_aad already for unicast
OSCORE, and that would be inherited for Group OSCORE, both for signing
and encrypting.
</MT>

> * 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.

<MT>
It's true that RFC 7641 does not say anything. However, Section 2.10 of
RFC 7390 says: "CoAP Observe does not support a group communication
mode. CoAP Observe only supports a unicast mode of operation."

We can think more about the possibility of Observe over multicast, also
in the light of RFC 7390, and what this would imply in particular for
Group OSCORE, but right now we do not see why Observe should not work
out of the box with Group OSCORE.
</MT>

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

<MT>
This paragraph "Requests sent over Multicast ... possible
retransmissions." seems actually positioned in the wrong place.

It should rather be right before Section 5.1. Also, it should be
extended with an explicit reference to Section 2.5 of RFC 7390.
</MT>

> * 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.

<MT>
Actually, Section 4.3 of RFC 7252 says: "A Non-Confirmable message MUST
NOT be acknowledged by the recipient."
</MT>

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

<MT>
We can extend the paragraph right before Section 6.1 as follows.

"Furthermore, according to Section 5.2.3 of [RFC7252], responses to
Non-confirmable group requests SHOULD be also Non-confirmable. However,
endpoints MUST be prepared to receive Confirmable responses in reply to
a Non-confirmable group request.
</MT>

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

<MT>
We can extend Section 6.1 with the following third bullet point. Note
that the mentioned "step 5" refers to Section 8.1 of
draft-ietf-core-object-security.

* In step 5, the countersignature is computed and the format of the
OSCORE message is modified as described in Section 4.2. In particular,
the payload of the OSCORE message includes also the counter signature
(if present according to the bit flag).
</MT>

> * 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.

<MT>
We can clarify the following points:

1) An endpoint can asynchronously query the GM at any point in time, to
acquire information for processing incoming messages. Such requested
information includes especially public keys of group members.

2) An endpoint can asynchronously generate a Recipient Context whenever
it wants and it has the necessary information to do so. That is, a
Recipient Context may be generated well in advance receiving a message
from the corresponding endpoint for the first time.

3) An endpoint can "subscribe" to the GM for updates on the group
membership, i.e. for getting an updated list of Sender IDs in the group
upon membership changes. This can be achieved in a number of ways, e.g.
through Observe.
</MT>

> * 
>
>
>
> _______________________________________________
> core mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/core

-- 
Marco Tiloca
Ph.D., Senior Researcher

RISE Research Institutes of Sweden
Division ICT
Isafjordsgatan 22 / Kistagången 16
SE-164 40 Kista (Sweden)

Phone: [phone]
https://www.ri.se