> > Unless I'm missing something, it's not immediately clear for me how you want > > to use HPKE here. Can you clarify? > > Similar to how MLS is using it to (re)generate the keys for the binary tree. > They addressed the same > problem of having a group and members joining and leaving and ensuring left > members can’t decrypt > new messages anymore.
It seems to me taht the requirements for MLS and G-IKEv2 are a bit different. In G-IKEv2 (or generally in GDOI architecture) we have a group controller, which have a complete view of the group (it manages membership and generates and distributes all the multicast keys). Generally speaking, the controller may be out of the group (i.e. it may have no data to send to the members or to receive from them other than multicast keys). In my understanding in MLS there is no such a controller, the group is managed by its members and the keys are constantly updated by all members. In other words, in G-IKEv2 group management and key distribution is centralized, which is not the case for MLS. I didn't look into MLS deeply, but it seems to me that it is more suitable for low-bandwidth communications (like group chat), while G-IKEv2 approach is more appropriate for high-speed communications (e.g. live broadcasting). And you may want to know that there is a mechanism in G-IKEv2 that allows excluding group members (so that they cannot decrypt multicast data anymore) using only multicast messages (yes!). It is called LKH (Logical Key Hierarchy) and is currently a part of G-IKEv2 document. Such mechanisms are pluggable, more can be defined in future. Regards, Valery. _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
