Re: [core] Review of draft-ietf-core-oscore-groupcomm-05

[Marco Tiloca <[e-mail]>]

Hi Ludwig,

Thank you very much for your review! We have addressed your points in
the recently submitted v -06.

https://tools.ietf.org/html/draft-ietf-core-oscore-groupcomm-06

Please, see our replies inline below.

Best,
/Marco

On 7/24/19 2:13 PM, Ludwig Seitz wrote:
> Hello Marco, Göran, Francesca and Jiye,
>
> here are some review comments on draft-ietf-core-oscore-groupcomm-05:
>
>
> ==
> All document:
> Update references to OSCORE to point to RFC 8613
>

<MT>
Done.
</MT>

> ==
> 1.1
>
> Why allow collisions between Group Identifiers managed by a single GM?
> This seems unnecessary and dangerous, is there a good use-case where
> this is warranted?

<MT>
It does not have any security implications (see Section 8.5).

However, we are now mandating uniqueness of Group Identifiers under the
same Group Manager.
</MT>

>
> ==
> 2.
>
> Why not require the application to prevent collisions between Gids?

<MT>
Do you mean the application at the GM?

The group members cannot "prevent" collisions, but they can handle them,
e.g. trying to use the different matching contexts until one
successfully decrypts the incoming message.
</MT>

>
> ==
> 2.
> "If not already stored in the Recipient Context associated to the
> sender, the recipient retrieves the sender's public key from the Group
> Manager, which collects public keys upon endpoints' joining the  
> group, acts as trusted key repository and ensures the correct
> association between the public key and the identifier of the sender,
> for instance by means of public key certificates."
>
> Note that this requires a device to have two parallel sessions open
> (one with the GM and one on which the message linked to the
> potentially missing public key. This may not always be feasible on
> very constrained devices.

<MT>
We have added some considerations on this, in the third paragraph after
the table in Figure 1.
</MT>

>
> ==
> 2.1.
> "After a new Gid has been distributed, a same Recipient ID ('kid')
> should not be considered as a persistent and reliable indicator of
> the same group member.  Such an indication can be actually achieved
> only by verifying countersignatures of received messages."
>
> This is really counter-intuitive and dangerous. Why can identifiers be
> redistributed within the same group? Shouldn't the GM make sure that
> the same identifier is assigned to a group member, even if the
> security context is updated? If the only reliable identifier is the
> public key, why not make the sender/recipient ID a hash of that public
> key?

<MT>
There is (at least) a case where the GM can assign a new Sender ID to a
current group member. If that node experiences a wrap-around of its own
Sender Sequence Number (used as Partial IV), the node reports that to
the GM. As an alternative to perform a full group rekeying, the GM may
choose to assign a new Sender ID to that sender node, which will
consequently derive a new Sender Key and can resume sending messages
starting from Sender Sequence Number 0. See also [1]. Of course, this
will result in the recipient nodes to derive a new associated recipient
context.

As to the second part of the comment, some group members are not
(necessarily) associated with a public key provided to the GM. This
applies to the "silent servers", that received only and never sends
outgoing message to sign.

[1]
https://tools.ietf.org/html/draft-ietf-ace-key-groupcomm-oscore-03#section-7
</MT>

>
> ==
> 3.
> "... with an Authenticated Encryption with Additional Data (AEAD)
> algorithm"
>
> AEAD expands to "Authenticated Encryption with Associated Data"

<MT>
Ooops. That was an oversight.
</MT>

>
> ==
> 3.1
> "The external_aad in the Additional Authenticated Data (AAD) is
> extended as follows."
>
> As far as I can tell the external_add is not "in" the AAD, it is the
> AAD, so I'd suggest to rephrase to "The external_aad structure of the
> Additional Authenticated Data (AAD) ..."
<MT>
Based on [2], it does not seem to be a one-to-one correspondence. The
external_aad is used to build the AAD.

Anyway, a phrasing like "The external_aad of the Additional
Authenticated Data (AAD) ..." looks good.

[2] https://tools.ietf.org/html/rfc8613#section-5.4
</MT>

>
> ==
> 7.
> "2. [...] Such policies can be enforced locally by the Group Manager,
> or by a third party in a trust relation with the Group Manager and
> entrusted to enforce join policies on behalf of the Group Manager."
>
> This feels unnecessary in the context of this document, since it
> doesn't deal at all with the how/where/why of the policies governing
> access to a group. I would suggest to delete this sentence.

<MT>
I tend to agree with your view. We have now removed that sentence.
</MT>

>
> ==
> 7.
> "3.   Driving the join process to add new endpoints as group members."
>
> This sounds weird. What does "driving the process" mean? Perhaps just
> rephrase to "handle the join process"?

<MT>
Yes, that sounds good.
</MT>

>
> ==
> 7.
> "4.   Establishing Security Common Contexts ..."
>
> This part of the sentence sounds like there is an unintentional word
> swap. Did you mean "Establishing the Common Context part of the
> Security Context"?
>
> Note that the term "Security Common Context" appears in several other
> places throughout the document.

<MT>
Yes, now rephrased also to refer to "Common Context" (all over the
document).
</MT>

>
> ==
> 8.3
> "... a key management scheme for secure revocation and renewal of
> Security Contexts and group keying material ..."
>
> Isn't the "group keying material" part redundant? If I understood
> everything correctly it is part of the Security Contexts.

<MT>
In a simple case, the only group keying material is part of the Group
Security Context.

In general, the GM may use advanced group key management schemes that
also rely on multicast messages to rekey the group more efficiently.
These schemes leverage on additional administrative group key material,
used to securely perform group rekeying.

So "group keying material" above was intended to cover also such
administrative keys. Perhaps it helps to give an intuitive pointer to
this in the text.
</MT>

>
> ==
> 8.4 Second paragraph.
>
> If I read this correctly you propose that applications
> allow recipients to continue using invalid security contexts for a
> limited time after a security context update. This sounds dangerous
> and unnecessary. Why would we want to propose such a measure? We could
> adopt the equivalent procedure here to the one proposed in the third
> paragraph, that is "If a sender receives a Security Context update
> shorty after having sent a message, it can re-send that message using
> the new Security Context."

<MT>
We are leaving the final choice to the application, while still not
recommending this choice and explaining its downsides (end of the second
paragraph).

As to your proposed alternative, I was thinking of the following
sequence of events, considering that C cannot tell for sure if/when S
has switched context.

1. C sends a message M protected with ctx_old.
2. S receives M, decrypts it with ctx_old, and processes it.
3. C and S switch to ctx_new , i.e. S is not much faster than C in its
switching (but C cannot know).
4. C re-sends M protected with ctx_new.
5. R receives M, decrypts it with ctx_new, and processes it again.

So, if S was not much faster than C in its context switching (like
instead discussed in the draft), this re-sending would result in S
processing the same request twice, which is probably not the intention of C.

To make things a bit better, C does not re-send M if it has received a
response from S to the original M. However, what if S just does not
respond or the response is lost? Note that requests over multicast are
Non-CON.
</MT>

>
> ==
> 8.5
>
> Why would an application even allow non-unique group identifiers? This
> makes the whole concept of the group identifier useless. Is there a
> realistic use case where this could happen? Otherwise I suggest
> removing this text.

<MT>
See response above.

I suppose this refers specifically on uniqueness of Group Identifiers
under the same GM. There is not so much you can do for groups under
different (non-synchronized) Group Manager, and just handle possible
collisions at the application.
</MT>

>
> ==
> 8.9
> "Group OSCORE derives the Security Context using the same construction
> of OSCORE"
>
> should be: ...same construction as ...

<MT>
Fixed.
</MT>

>
> ==
> 8.10
> "Thus, other that in such unlikely case, it cannot be defined that
> only messages with sequence number which are equal to previous
> sequence number + 1 are accepted."
>
> I cannot make sense of this sentence, please rephrase, possibly
> splitting it into several sentences.

<MT>
Rephrased as: "Thus, unless only unicast messages are sent in the group,
it cannot be defined that only messages with sequence numbers that are
equal to the previous sequence number + 1 are accepted."
</MT>

>
> ==
> 8.14
> "...this parameter explicitly relate two or more communicating
> endpoints,"
>
> should be "...explicitly relates two ..."

<MT>
Fixed.
</MT>

>
> ==
> 9.1 and 9.2
>
> Would be nice if there was a sentence or two explaining the difference
> between the two registries, as it is not immediately obvious.
>

<MT>
Done.

Note that, taking advantage of the latest updates to the COSE drafts,
we're going to remove the two registries and instead point at:

https://www.ietf.org/id/draft-ietf-cose-rfc8152bis-algs-06.html#name-iana-considerations
</MT>

> ==
> 9.3
> "The IANA Registry established in this document is defined"
>
> should be "Registries ... are defined"

<MT>
Fixed.
</MT>

>
> ==
> Appendix B 5th bullet
>
> The abbreviation LLN should be expanded.

<MT>
Done.
</MT>


>
> ==
> Appendix B 6th bullet
>
> " The latters may reply back ..."
>
> Should be "The latter ..."

<MT>
Done.
</MT>

>
> ==
> Appendix B 6th bullet
>
> Expand the abbreviation "MPL"

<MT>
Done.
</MT>

<MT>
Thank you very much again for your review!
</MT>

>
>
>
> Regards,
>
> Ludwig
>
>
>

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