GDOI GROUPKEY-PUSH Acknowledgement Message
Note: This ballot was opened for revision 06 and is now closed.
Kathleen Moriarty Yes
Deborah Brungard No Objection
Ben Campbell No Objection
Comment (2017-08-29 for -06)
- 4: "If a GM does not intend to respond with Acknowledgements,..." The previous paragraph said a GM that recognizes the ack request MUST return an acknowlegement. I assume this sentence refers to GMs that do not recognize the request, but it seems to allow any GM to just decide not to respond.
Spencer Dawkins No Objection
Suresh Krishnan No Objection
Warren Kumari No Objection
Comment (2017-08-28 for -06)
Thanks for addressing Michael's comments. I'd also like to thank Adrian for a nice shepherd writeup....
Mirja Kühlewind No Objection
Comment (2017-08-25 for -06)
- Thanks for addressing the very good gen-art review comments (And thanks Roni!) - I guess the GM could indicate at registration time that it is able and willing to support ACKs. While this information is maybe not super helpful, it could potentially be used to detect network problem, e.g. that ACKs are dropped. Was this considered? - sec 6: „A GM MAY introduce a jitter to the timing of its Acknowledgement message“ -> I guess the server could also send out the push messages with jitter while the GM replies immediately. In this case there is less uncertainty when the ACK will be sent and how long the server has to wait for it. Was this considered? - sec 7.1: „ Therefore, there is no direct value that the attacker derives from the knowledge of the sequence number.“ -> Doesn’t knowing part of the encrypted text in clear potentially help to break the encryption? Should this be considered?
Terry Manderson No Objection
Alexey Melnikov No Objection
Comment (2017-08-30 for -06)
I agree with Adam's DISCUSS and comments.
Eric Rescorla No Objection
Alvaro Retana No Objection
Adam Roach (was Discuss, No Objection) No Objection
I was going to make the same comment Ben did about "...does not intend to..." but he beat me to it. The document uses 2119 language, but doesn't appear to do so reliably (see, e.g., the "must" in section 3.1, and many instances of "may" throughout the document that appear to be normative). I suggest a pass through the document to ensure the use of 2119 terms is as intended. Section 3.2, in describing the format of "L" in the ack_key derivation, needs to indicate byte order (I suspect you mean to say something like: "...as two octets in network order (that is, most significant byte first)."). I would also suggest that the guidance around detecting that a GM has left the group require that the GCKS receive at least one Ack from the GM before it uses the absence of an Ack to indicate that it has left; as the document notes, there are a number of reasons that the GCKS may not receive the Acks.