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

From: Yaron Sheffer <[email-masked]>
Date: Sat, 05 Aug 2017 08:49:05 -0700

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.

* "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.

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Thu, 24 Aug 2017 16:48:46 +0000

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 <[email-masked]<mailto:[email-masked]>> wrote:

Reviewer: Yaron Sheffer

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.

Point taken. We’ve changed the text to reflect this.

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.

We’ve made this change.

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..

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.

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.

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: +1 408 526 4796
Email: [email-masked]<mailto:[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Sat, 26 Aug 2017 18:34:44 +0300

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.
> 
> 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.
>>
>> *//*
>>
> 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.
> 
> 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.
> 
> 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..
> 
> 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.
> 
> 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.
> 
> Email: [email-masked] <mailto:[email-masked]>
>

---

From: "Brian Weis (bew)" <[email-masked]>
Date: Tue, 29 Aug 2017 20:48:18 +0000

Hi Yaron,

On Aug 26, 2017, at 8:34 AM, Yaron Sheffer <[email-masked]<mailto:[email-masked]>> wrote:

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.

Sorry, we missed this. Incremental deployment of any new policy (algorithm or otherwise) within a group is not so straightforward. There can really only be one set of policy used by the entire group because if a sender has been updated to a new set of policy it can’t really use it until all receivers are similarly upgraded. This is a place where a capabilities exchange can be useful for a key server to declare a switch to a new algorithm after all members claim to support it, but that might never happen in a large group. Practically speaking incremental updates in a large group might require two different groups with a bridge between, or some other deployment structure. Since it’s a broader problem, I’m not sure what else we can do in this document to address incremental deployment.

Thanks,
Brian

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 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Reviewer: Yaron Sheffer

*//*

Email: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

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 <[email-masked]<mailto:[email-masked]> <mailto:[email-masked]>> wrote:

Reviewer: Yaron Sheffer

*//*

Email: [email-masked]<mailto:[email-masked]> <mailto:[email-masked]>

---

From: Yaron Sheffer <[email-masked]>
Date: Tue, 29 Aug 2017 23:59:58 +0300

Hi Brian,

To me, incremental deployment is what crypto-agility is all about. But I 
guess others might disagree. In any case, this limitation needs to be 
discussed when we talk about agility.

Thanks,
	Yaron

On 29/08/17 23:48, Brian Weis (bew) wrote:
>> Thank you for addressing most of my comments in the new version, and 
>> for clarifying points where I was off the mark.
>>
>> question is whether we support incremental deployment of a new 
>> algorithm to a large group of GMs.
> 
> Sorry, we missed this. Incremental deployment of any new policy 
> (algorithm or otherwise) within a group is not so straightforward. There 
> can really only be one set of policy used by the entire group because if 
> a sender has been updated to a new set of policy it can’t really use it 
> until all receivers are similarly upgraded. This is a place where a 
> capabilities exchange can be useful for a key server to declare a switch 
> to a new algorithm after all members claim to support it, but that might 
> never happen in a large group. Practically speaking incremental updates 
> in a large group might require two different groups with a bridge 
> between, or some other deployment structure. Since it’s a broader 
> problem, I’m not sure what else we can do in this document to address 
> incremental deployment.
> 
> Thanks,
> Brian
> 
>>
>> Thanks,
>> Yaron
>>
>>> 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 <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>> Reviewer: Yaron Sheffer
>>> 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.
>>>>
>>>> *//*
>>>>
>>> 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 
>>> 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 
>>> 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.
>>> 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.
>>> GCKS to detect replays. This is arguably better placed in this 
>>> section, so we’ve moved it here..
>>> 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.
>>> Email: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
>>
>>
>> Thanks,
>> Yaron
>>
>>> 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 <[email-masked] 
>>>> <mailto:[email-masked]> <mailto:[email-masked]>> wrote:
>>>>
>>>> Reviewer: Yaron Sheffer
>>> 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.
>>>>
>>>> *//*
>>>>
>>> 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 
>>> 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 
>>> 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.
>>> 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.
>>> GCKS to detect replays. This is arguably better placed in this 
>>> section, so we’ve moved it here..
>>> 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.
>>> Email: [email-masked] <mailto:[email-masked]> <mailto:[email-masked]>
> 
> -- 
> Brian Weis