Summary: this reviewer is not clear about the value of the push-ack (compared to a pull) and about the strategy that was chosen. * "For example, a GCKS policy can use the acknowledgements to determine [...] which members may no longer be members of the group." This sentence is very confusing: when are members not members? * The new protocol capability is defined as optional, but really isn't. "A GM receiving the KEK_ACK_REQUESTED attribute can choose to ignore it, thus appearing as if it does not support the KEK_ACK_REQUESTED attribute. However, GCKS policy may consider a non-responsive GM to no longer desire to be a member of the group." So if you want to play the game, you MUST support the new attribute. * I'm puzzled at the overall protocol. Being able to send ACKs is a GM software capability. Why not have the GM announce this capability when it initially registers to the GCKS? Then the GCKS would know what to expect, whereas with the current protocol it is left waiting for an ACK that may never come, either because the GM is dead or because it just doesn't feel like responding. Add the long waits (jitter of "a few seconds" and potential retries), and this looks like a far from optimal management experience. * 2.2: "This is a private key" - to avoid confusion, I suggest: "This is a secret symmetric key" (if this is indeed the case). Obviously using the same key for encryption and for HMAC is not a best practice. * Sec. 5: ACK messages can also be duplicated in the network. I suggest to add a sentence describing what the GCKS should do in this case. * Sec. 6: I am confused about the notion of "jitter" here. If the PUSH messages are sent as multicast (the recommended alternative AFAICT), I'm not sure about the benefit of using multicast, given that each recipient responds with a unicast ACK. And if the PUSH is unicast, there should be no reason for a jitter as the sender can throttle the PUSH messages as necessary. * Moreover, everything would be much more predictable if the GCKS could indicate if a jitter is expected and how much of a jitter (based on size of the group, network throughput, and queue length). Specifically, this would allow the GCKS to tell how long it should wait for an ACK. * Cryptographic agility: this document specifies only one algorithm for the HASH value, and says that if a new algorithm is needed, there will be a new KEK_ACK_REQUESTED payload defined. However to make sure that this really "works", we need to define whether multiple such payloads can be sent simultaneously (if e.g. some GMs still support the old algorithm) and what's the expected behavior. I would suggest to define an additional SHA-512 payload just to make for a concrete example.