Last Call Review of draft-ietf-ace-key-groupcomm-17
review-ietf-ace-key-groupcomm-17-tsvart-lc-goel-2023-10-13-00

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

As I am not very familiar with this topic, most of my comments are editorial
except a few. My comments are only suggestions to improve the text and I'd
happy to discuss them if needed.

COMMENTS:
Section 1.1 : “NODENAME: the invariant once established text string used in
URIs to identify a member a group.”
Typo at the end of the sentence.

OLD: to identify a member a group.
NEW: to identify a member of a group.

Section 2: “Client (C): node that wants to join a group and take part in group
communication with other group memebrs.” Typo in the last word- members.

Section 2: “Examples of a Dispatcher are:”
Does this need to include anycast addresses?

Section 3.3.1:”in the groups indicated by the transferred acces token as per
its 'scope' claim”
Typo in the word - access.

Section 4.1:
For all the resources defined, can authors double check if “Clients may be
authorized to access this resource even without being group members” is
mentioned for all applicable resources.

Section 4.1.2: “If the request includes unknown or non-expected fields, the
handler MUST silently ignore them and continue processing the request.”
Is this
safe to silently ignore such requests? Please double check.

Section 4.2.1.1. “In case the joining node only knows the group identifier of
the group it wishes to join or about which it wishes to get update information
from the KDC”

Did you mean to say “.. to get updated information..”?

Section
4.4.1.1. Is it possible to include an example of authentication credential
request-response for more than 1 group members?

Section 5:

OLD: “…if it acts as repository of authentication credentials for group
members.” NEW: “…if it acts as a repository of authentication credentials for
group members.”

Similar text “KDC acts as repository” is present elsewhere and can be updated
like above.

Section 6.1: “This approach consists in the KDC sending one individual rekeying
message to each target group member.” The beginning of this sentence doesn’t
seem right. Can you double check?

Section 6.2.1: 
OLD: “The used encryption algorithm which SHOULD be the same
one used to protect communications in the group.” NEW: “The used encryption
algorithm SHOULD be the same one used to protect communications in the group.”

Section 6.3: Paragraph starting with “In the second case, the sender protects a
message using the new group keying material, but the recipient receives that
message before having received the new group keying material.”

Another
suggestion to deal with this case: The recipient can store a message that it
can’t decrypt temporarily for a limited time so that if it receives new group
keying material shortly after, it can then decrypt those stored messages.

Section 10.
DDOS attack possibilities - I can see some possibilities for DDOS
where Clients can overwhelm KDC by sending unexpected or unknown fields. There
might be more - can authors provide some possible DDOS attack vectors?

Thanks,
Vidhi