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

[Yaron Sheffer <[e-mail]>]

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:
> Hi Yaron,
> 
>> On Aug 26, 2017, at 8:34 AM, Yaron Sheffer <[e-mail] 
>> <mailto:[e-mail]>> 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 <[e-mail] 
>>>> <mailto:[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]> <mailto:[e-mail]>
>>
>>
>> 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]> <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]> <mailto:[e-mail]>
> 
> -- 
> Brian Weis
> Security, CSG, Cisco Systems
> Telephone: [phone]
> Email: [e-mail] <mailto:[e-mail]>
>