7.6.7 Leader Participant List

A meeting leader maintains a “leader participant list” (LPL) tabulating all the users in the meeting. For each user currently in the meeting, the LPL keeps track of a hash over their Bindingi , which includes their IV Ki , pki , userID, and hardwareID, as well as their display name. For users who have left the meeting, the LPL tracks only their userID, hardwareID, IVKi , and display name. The LPL is used to drive the participant list in the user interface, which records both users currently in the meeting and those who have left. Currently, the participant list in the user interface only identifies users through their selfselected display name and profile picture. Changes to participants’ display names are relayed by the server to the leader who includes them in the LPL: a compromised server can change the display names of any meeting participant. As such, display names should not be relied on to establish the participants’ identities. Attestations from identity providers (Section 7.10) can also strengthen in-meeting identity by displaying additional identifiers that cannot be tampered with. Later, we will introduce a strong notion of cryptographic identity in meetings (Section 3) to further address these limitations. The LPL is represented as a sequence of operations such as adding a user to the meeting, or noting when a user has left. Every time there is such an operation, the leader increments a counter v representing the total number of operations and signs over a data structure (called a link) containing the counter, the hash of the previous link, and the current operation. If there are more than 20 links in the chain, the leader can coalesce all the previous links into a smaller number of links. The old links are then deleted in order to save space. Leaders post a signature over the latest link to the bulletin board whenever membership changes, and broadcast it over the signaling channel at designated “heartbeat intervals”: Hi = SHA256(BindingkSHA256(LPLv)kvktkmkSeqNumkHi−1ktimestampl ) Si = Sign.Sign (ISK , Context, Hi) where Context is "Zoombase1-ClientOnly-Sig-LeaderParticipantList", t increments on every send, v increments whenever the LPL changes, mkSeqNum increments on every MK rotation, Hi−1 is the previous heartbeat’s hash, and timestampl is a monotonically increasing timestamp as recorded by the leader’s local clock. By replaying the sequence of operations in the bulletin board, the other participants can reconstruct the current list of participants, so they know who to rekey for if the leader drops out and they become the new leader. Evil servers might try to withhold updates the leader makes here, to hide when bad actors are kicked out. As such, the leader also sends a low bandwidth “heartbeat” over the signaling channel. Heartbeats should go out at least every 10 seconds. All participants observe and verify these heartbeats, and if they fail to receive ten heartbeats in a row, they should drop out of the meeting. This mechanism prevents the server from withholding updates to the LPL for an extended period of time. Heartbeats certify both the mkSeqNum and the list of participants for whom mkSeqNum is accessible. Because users wait for the heartbeat certifying a certain meeting key before encrypting with it, the participant list in the user interface always reflects the list of participants users are encrypting for. When a leader does drop out of a meeting, the Zoom server picks a new leader arbitrarily and sends a signal to participants indicating that the leader has changed. The new leader then coalesces the chain as described above, and other participants verify that the new leader is present in the new LPL. For users in the meeting, clients remember the mapping between (userID, hardwareID) and hash over the corresponding Bindingi , and ensure that the hash remains stable across new links and leader changes. If a user leaves the meeting, it is enforced that any user who rejoins with the same userID and hardwareID must have the same IVKi , but not necessarily the same pki . These guarantees persist only over the course of a single meeting. One unavoidable attack the Zoom server can perform is partitioning the meeting: for example, split the participants of an ongoing meeting in two groups (each with its own leader), and tell each group that the other half dropped out. Partitioning attacks cannot be avoided while tolerating participants abruptly dropping out of meetings. However, since each heartbeat includes the previous heartbeat’s hash in the signature material, if two participants accept the same heartbeat (i.e., they are in the same partition) they must also agree on the history of the meeting. In other words, partitions cannot be reconciled as their heartbeat chains have diverged. Note: Before Zoom client version 5.13, the heartbeat signature did not include the previous heartbeat’s hash in the signature material. As such, different meeting participants might have disagreed on the past history of the meeting, in the case of meeting partitions due to bad network conditions or server compromise.