Last Call Review of draft-weis-gdoi-rekey-ack-05
review-weis-gdoi-rekey-ack-05-secdir-lc-sheffer-2017-08-05-00

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.