Re: [secdir] Secdir last call review of draft-weis-gdoi-rekey-ack-05

[Yaron Sheffer <[e-mail]>]

Hi Brian,

Thank you for addressing most of my comments in the new version, and for 
clarifying points where I was off the mark.

The only remaining comment that's only partly addressed is the one on 
crypto agility. Quoting myself:

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.

In other words, supporting more algorithms in not sufficient. The 
question is whether we support incremental deployment of a new algorithm 
to a large group of GMs.

Thanks,
	Yaron

On 24/08/17 19:48, Brian Weis (bew) wrote:
> Hi Yaron,
> 
> Thanks for the review. We’ve added some clarification below, and made 
> some changes in -06 to address your comments. Please let us know if we 
> did not address them satisfactorily.
> 
>> On Aug 5, 2017, at 8:49 AM, Yaron Sheffer <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Reviewer: Yaron Sheffer
>> Review result: Has Issues
>>
>> Summary: this reviewer is not clear about the value of the push-ack 
>> (compared
>> to a pull) and about the strategy that was chosen.
> 
> In a group key management system either a “pull” (triggered by a group 
> member) or a “push” (by the key server)" could be used to provide 
> updates to the group. However, a “pull” by the group member implies a 
> polling method, which has the deficiency that the key server cannot 
> cause a policy replacement any sooner than the polling method by the 
> group members. Also “polling” can cause additional unnecessary traffic. 
> So is is better for any update on the group policy or renewal of group 
> keys to be distributed by the GCKS using a PUSH message. The ACK-message 
> is used to offer a feedback mechanism to a policy update for the PUSH 
> exchange.
>>
>> *//*
>>
>> * "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?
> 
> We’ve reworded this text. It’s trying to convey that a missing ACK 
> message (or a certain number of it) can be used to identify that a group 
> member is no longer receiving group traffic, and is now may be 
> considered an ex-group member. For example, it could be a multicast 
> receiver that is no longer interested in being a receiver for the group. 
> But it could also be that a network event has caused it to be 
> unavailable for a sufficient length of time such that it doesn’t have 
> current keying material and therefore can’t be considered a current 
> group member. There is no reliable “I’m leaving the group” message flow, 
> and of course in my second example no such messages would have been 
> intended by the group member.
> 
>> * 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.
> 
> Point taken. We’ve changed the text to reflect this.
> 
>> * 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.
> 
> Indeed a GM could announce its capability, but whether or not ACKs are 
> desired is a component of the group policy. In the context of GDOI the 
> GCKS is the entity that defines the group policy. There can be groups 
> where the ACK is used, whereas others do not.  The capabilities 
> announcement you suggest could certainly help the KS to know whether or 
> not to expect the ACK from a particular GM, but the focus of this I-D is 
> on the the declaration of the request for ACKs by the GCKS and the 
> format of the ACK.
> 
>> * 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.
> 
> We’ve made this change.
> 
>> * 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.
> 
> The Security Considerations (section 7.3) describes a method for the 
> GCKS to detect replays. This is arguably better placed in this section, 
> so we’ve moved it here..
> 
>> * 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.
> 
> The concept of “jitter” is most valuable for responses to a multicast 
> PUSH message. The use of a multicast PUSH message lower processing on 
> the GCKS. Since each GM can e given the exact same policy, there’s no 
> call to send it out as a unicast message. The jitter helps spread out 
> the replies a bit to avoid inundating the GCKS.
> 
>> * 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.
> 
> This would be somewhat useful, but in practice might not help the GCKS 
> as much as it seems. The jitter value provided would also be dependent 
> on several network parameters that aren’t under the control of the GCKS 
> or the GM. Even when the GM does not add any jitter to the ACK, the 
> underlying network may delay the PUSH and/or for the ACK. And as stated 
> in Section 6, the GCKS may be configured with additional policy actions 
> like retransmissions to overcome lost ACKs. Altogether to add jitter to 
> the ACK is not a must, it is a way to help the GCKS deal with a huge 
> number of GMs. In practice, we’ve found that having the GMs choose the 
> jitter has worked well, even when the GMs are different implementations.
> 
>> * 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.
> 
> This is a good suggestion. We’ve added SHA-512 versions of the existing 
> KEK_ACK_REQUESTED values.
> 
> See <https://tools.ietf.org/html/draft-weis-gdoi-rekey-ack-06>
> 
> Thanks,
> Brian
> 
> -- 
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: [phone]
> Email: [e-mail] <mailto:[e-mail]>
>