karanlyons
commented
4 years ago • Phase 1 - Client Key management - Please Clarify the PSTN join options for E2E meetings , whom is greyed out , is E2E available in the meeting for everyone but the PSTN users are greyed out, or is E2E not possible for all if there is a PSTN user in the meeting? Do the PSTN users get denied the meeting?
In phase 1 E2E meetings will only allow native clients.
• In phase 1 - Can we schedule an E2E meeting versus a non E2E meeting (if we know there is a large component of dial in users? )
Yes, and it will be possible to upgrade a running meeting to E2E in later phases.
. • Phase 1 - Client Key management Clarify regenerate encryption keys during meetings ? This as it is written sounds unmanageable for large meetings : "The leader should trigger a rekey whenever a participant enters or leaves the meeting, but not more than every 15 seconds (to prevent thrashing" , is this required ? If we have application prevent users without 3 signatures in phase 4?
This is handled automatically by the client: it is not a manual process and will not have a noticeable impact on meetings of large sizes.
• Phase 1 - Client Key management - Does meeting rekeying require participants to keep track of users manually, how is this accomplished " The other participants should know this list, so they know who to rekey for if the leader drops out and they become the new leader. " ? Commonly we have calls with many participants that we have never had a meeting with, how do we generate keys for large new ad hoc meetings ?
These keys are generated by the clients automatically, and require no manual effort from users. The experience will be seamless.
• Deprovisioning phase 2: I assume there will be some more Enterprise Device Management strategy that will automate some of this need? "When a user uninstalls Zoom on a device, or erases, throws away, or loses a device, they should sign a statement saying that the device is revoked. This way, if anyone shows up later using this device, other meeting participants can cast a suspicious eye." Can we build this into the software notifications?
We will build this in such a way to make it easy for a user to revoke one device from another with the push of a button; we will utilize different UX methods to make this easily available.
• Phase 3 TT - "Because we only trust keys stored within the ZTT, users in a meeting will verify that each other’s public keys are included in the ZTT, before proceeding with key exchange as in Phase I. If the verification fails, the client will fail to join the meeting. " Clarify - How is this going to work for external guests , is this an out of band communication ? How do we know they verified the ZTT with an auditor ? Or guests that do not have a Zoom paid instance ?
The keys for all Zoom users will appear in the ZTT, whether they are part of your organization, another organization, or an individual user without a paid account. These queries to the ZTT will happen automatically by the client.
Auditing happens entirely out of band. If an audit fails, the auditor will publicise the failure. Thus, the participants in the meeting do not need to check with the auditor individually; it is safe to assume that the audit is happening in the background and they will find out through the news if it has failed.
• Phase IV: Real time security - "devices with just two signatures can appear “degraded.” These degraded devices will trigger warnings in the UI, or would be excluded from meetings marked “high security.” Clarify, where is the high security marking ? What message would they get, can the organizer downgrade the meeting to admit these users, this seems like operational support would be difficult?
The UI for Phase IV features is still under design. Thank you for your input; we will share these plans in the future as we solidify our designs and will take into account operational load both for account administrators and individual users.
• Phase 1 - Client Key management - Please Clarify the PSTN join options for E2E meetings , whom is greyed out , is E2E available in the meeting for everyone but the PSTN users are greyed out, or is E2E not possible for all if there is a PSTN user in the meeting? Do the PSTN users get denied the meeting? • In phase 1 - Can we schedule an E2E meeting versus a non E2E meeting (if we know there is a large component of dial in users? ) • Phase 1 - Client Key management Clarify regenerate encryption keys during meetings ? This as it is written sounds unmanageable for large meetings : "The leader should trigger a rekey whenever a participant enters or leaves the meeting, but not more than every 15 seconds (to prevent thrashing" , is this required ? If we have application prevent users without 3 signatures in phase 4? • Phase 1 - Client Key management - Does meeting rekeying require participants to keep track of users manually, how is this accomplished " The other participants should know this list, so they know who to rekey for if the leader drops out and they become the new leader. " ? Commonly we have calls with many participants that we have never had a meeting with, how do we generate keys for large new ad hoc meetings ? • Deprovisioning phase 2: I assume there will be some more Enterprise Device Management strategy that will automate some of this need? "When a user uninstalls Zoom on a device, or erases, throws away, or loses a device, they should sign a statement saying that the device is revoked. This way, if anyone shows up later using this device, other meeting participants can cast a suspicious eye." Can we build this into the software notifications? • Phase 3 TT - "Because we only trust keys stored within the ZTT, users in a meeting will verify that each other’s public keys are included in the ZTT, before proceeding with key exchange as in Phase I. If the verification fails, the client will fail to join the meeting. " Clarify - How is this going to work for external guests , is this an out of band communication ? How do we know they verified the ZTT with an auditor ? Or guests that do not have a Zoom paid instance ? • Phase IV: Real time security - "devices with just two signatures can appear “degraded.” These degraded devices will trigger warnings in the UI, or would be excluded from meetings marked “high security.” Clarify, where is the high security marking ? What message would they get, can the organizer downgrade the meeting to admit these users, this seems like operational support would be difficult?