Last Call Review of draft-ietf-ace-key-groupcomm-17
review-ietf-ace-key-groupcomm-17-artart-lc-thompson-2023-10-31-00

Document: Key Provisioning for Group Communication using ACE [1]
Intended RFC status: Proposed Standard
Review type: artart - Last Call review
Reviewer: Henry S. Thompson
Review Date: 2023-10-@@
Result: Ready with Issues

*Summary*

Caveat: I'm not familiar with the group comms family of RFCs or the
applications they support, so this review is from an outsider's
perspective.

As such, I am not able to comment on the adequacy of section 4.  This
is where the details of the Client and KDC interactions are spelled
out, and it needs a potential user of this spec. to judge whether they
provide the necessary functionality.

*Substantive points*

Section 2.  I'm seeing an inconsistency in the way the Dispatcher is
discussed.  When introduced in the bullet points the last bullet says

 "If it consists of an explicit entity such as a pub-sub Broker or a
  message relayer, the Dispatcher is comparable to an _untrusted_
  on-path intermediary, and as such it is _able to read_ the messages
  sent by Clients in the group." [emphasis added]

But at the end of section 2 we find

   "5. The joining node can communicate _securely_ with the other group
       members, using the keying material provided in step 3."
       [emphasis added]

If the Dispatcher is untrusted, how can communication be secure?
There is no discussion of the Dispatcher in the Security section.

Section 5: I don't see how authority to institute forced deletion is
established.  Indeed the means for forced deletion don't appear to be
defined at all.  Section 4.8 (and 4.8.3) explicitly requires that only
the Client can send a Delete request, and only for themselves.

*Minor points*

Section 1. I note that one of the two referenced examples of candidate
application profiles, "A publish-subscribe architecture for the
Constrained Application Protocol (CoAP)" [2], has expired.  I'm not
sure how much it matters to have reasonably mature examples, but
without _some_ good reasons to suppose that there's a community out
there waiting to implement this framework, its future does seem a bit
shaky...  There is of course a chicken-and-egg problem here which may
explain the lack of progress.

Section 2. This is the first point where the actual connection between
ACE and this document is made clear, that is, that the KDC is the
Resource Server _per ACE_.  Simply adding ", per ACE," to "Resource
Server" in para 2 of Section 1 would fix this for me.

Section 6: It might be helpful to include ASCII-art diagrams of the
different communication pathways described for accomplishing rekeying.

Sections 3.1 & 7: The example scopes include Verifier and Monitor
roles.  Although there is a parenthetical reference to the [Vv]erifier
role in Section 3.3.1, no other mention of Monitor is given, and in
general the role of roles is not explained anywhere. There is a
"Request inconsistent with the current roles" error code defined in
section 9, but no tabulation of roles allowed/required for particular
requests, which one might expect.  Nor are any REQ or OPT obligations
provided to cover this.

If all this is something defined in one of the many referenced specs,
and so familiar to likely readers, that's OK, otherwise perhaps
something should be added.

Sections 11.6--11.16: _Seven_ new IANA registries!  At a quick count,
that's a 50% increase in the number of related (CBOR + COAP)
registries.  Is there a plan for populating the expert reviewer slots
this entails?

*Nits*

Section 1 / Appendix A:  The use of REQ[n] and OPT[n] in conjunction
with REQUIRED and MAY is not explained, nor are they linked to the
relevant text in Appendix A.  There is an oblique reference to this
practice in para. 4 of Section 1, which could stand to be expanded to
explain your conventions.

Passim: Please do a thorough spell-check.  The following were found in the
first 4 sections:
  recommeded -> recommended
  memebrs -> members
  specificaton -> specification
  acces -> access
  trasferring -> transferring

ht
-- 

[1] https://datatracker.ietf.org/doc/draft-ietf-ace-key-groupcomm/
[2] https://datatracker.ietf.org/doc/html/draft-ietf-core-coap-pubsub-12