6.7 Security Properties

Zoom Mail Service shares the goals, threat model, and limitations of Section 2 with the other products outlined in this document. In this case, we stress that Zoom servers get access to email metadata such as message size, send time, recipient list, number of attachments, attachment sizes, information on threading (e.g., whether an email is a response to a previous email), and in some cases (e.g., when replying or forwarding), whether two emails share the same attachment. Moreover, in future releases user reporting of potentially inappropriate content may share decrypted email content with Zoom servers, though this functionality is not available as of version 5.12.8. The email encryption format is key-committing (each ciphertext, even if maliciously generated, can only be decrypted to a single plaintext) and guarantees both confidentiality and integrity, assuming the key material is kept private and correctly authenticated. Guarantees related to keys are inherited from the underlying key management architecture, as detailed in Section 3.11 (with the caveats below). For example, an attacker with readonly access to the Zoom server infrastructure and without access to any of the recipient’s devices cannot violate the confidentiality of E2EE email contents, or of non-E2EE emails whose processing has been completed (i.e. that have been sent out13 or encrypted for the recipient’s keys) before the compromise began. The user interface around fingerprints is still under active development (as of version 5.12.8, the product is still in beta). The current release only offers partial detection and prevention mechanisms against active attacks, which we are working to strengthen in the very near future. There is currently no way to mark that a fingerprint has been verified out-of-band so that the user gets notified when the corresponding sigchain changes. The guarantee that we offer is the following. Assume a user looks at a recipient’s fingerprint (by hovering on their name/email address) while in the compose window, and then hits “Send” without closing the compose window between the two operations. If so, the client enforces that the email will be encrypted using the latest email PUK that is part of the sigchain corresponding to the recipient fingerprint that the user saw. If the sigchain is updated before the user hits the “Send” button, the send operation will fail so that the user has the opportunity to check the updated fingerprint. We stress that this mechanism does not work if the user closes the window between seeing the fingerprint and sending the email, which may occur when continuing composing from a draft, or across different emails sent to the same recipient. We deem this an acceptable temporary solution until we are able to offer comprehensive support for remembering “trusted” fingerprints and notifications of fingerprint changes. We will continue to develop a more robust and feature-rich experience around fingerprints and change notifications, as well as more automated solutions such as those involving the ZTT to reduce the burden on the user. Lastly, while it is possible for the sender to check a recipient’s fingerprint before sending, there is currently no intuitive way for recipients to check the fingerprint of the sender of a given email to verify the claimed authorship. Support for this use case is also upcoming. Beyond key management, Zoom Mail Service does not make any guarantees regarding the following security properties: • Deniability (as ciphertexts are signed with the sender’s own device keys). • Authentication of email threading, ordering, or the relationship between forwarded messages (i.e. unrelated emails could be displayed as if belonging to the same thread or out of order, some emails might be hidden, and any quoted text in a reply or forwarded email can be altered by the responder/forwarder). • Authentication that an email has a particular label or is in a folder (e.g., whether an email has been “read”). • Rollback attacks on label/folder names or other encrypted non-email data (the server can always “undo” a rename by re-supplying the old signed ciphertext instead of the updated one). • Forward secrecy (users cannot delete key material related to, e.g., a single specific email). Post-compromise security. We offer partial guarantees: encryption keys are rotated as soon as possible after a device is explicitly revoked, and ciphertexts encrypted after the rotation cannot be decrypted using the old keys.

We will prioritize improving on these issues depending on customer feedback.