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 <yaronf.ietf@xxxxxxxxx
<mailto:yaronf.ietf@xxxxxxxxx>> 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 <yaronf.ietf@xxxxxxxxx
<mailto:yaronf.ietf@xxxxxxxxx> <mailto:yaronf.ietf@xxxxxxxxx>> 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: +1 408 526 4796
Email: bew@xxxxxxxxx <mailto:bew@xxxxxxxxx> <mailto:bew@xxxxxxxxx>
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 <yaronf.ietf@xxxxxxxxx
<mailto:yaronf.ietf@xxxxxxxxx> <mailto:yaronf.ietf@xxxxxxxxx>> 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: +1 408 526 4796
Email: bew@xxxxxxxxx <mailto:bew@xxxxxxxxx> <mailto:bew@xxxxxxxxx>
--
Brian Weis
Security, CSG, Cisco Systems
Telephone: +1 408 526 4796
Email: bew@xxxxxxxxx <mailto:bew@xxxxxxxxx>