5.6 Security Properties

When clients verify an IDP attestation, they obtain the following informal guarantee: the user who claims to control the cryptographic keys included in the attestation has successfully authenticated to the given IDP (w.r.t. to the email address in the attestation), and the owner of the attestation’s ADN domain has delegated the IDP to make these statements on the account’s behalf. This property relies on several assumptions. Beyond the security of the cryptographic primitives, the verifier relies on the web PKI to obtain the ADN’s DNS TXT entry from the DNS resolver Cloudflare over DoH, as well as the IDP’s public keys used to verify the attestations. A fraudulent attestation may also be produced upon compromise of the attested user’s device or of the user’s authentication credentials (including any two-factor authentication, if enforced by the IDP), or by compromising the IDP’s server infrastructure. Clients verify Zoom’s suggestion for an ADN’s preferred IDP through a DNS query. While relying on TLS (similarly to how JWKs are fetched) or DNSSEC would prevent some attacks from compromised DNS providers or network attackers, using a DNS TXT record eases the setup for our customers. We rely on Cloudflare as a trusted DNS resolver to confirm that the IDP indicated by Zoom is indeed the one the ADN owner intends to use. The DNS resolver can convince clients that a certain account is not using an IDP by e.g., returning a DNS NXDOMAIN message, or a wrong IDP value: in this case, because an honest Zoom and the ADN have returned different IDP domain values, the client will not consider the attestation valid and will not display the related information in the user interface. We stress that control of the Zoom server infrastructure alone is not sufficient to convince clients of a wrong IDP value. In the future, with the transparency layer offered by the ZTT (Section 4), any server tampering of an account’s ADN or IDP will be detected.

We plan to offer users other options for DNS resolvers in addition to 1.1.1.1 in the future. From a privacy perspective, users who opt into sharing attestations share a binding of their email address and the long-term device key(s) used by their devices, and thus reveal their user, account and device identifiers to their communication partners. We attempt to minimize the information disclosed to third-party servers: by using the Zoom-hosted HTTPS CONNECT proxies, the verifying client can avoid leaking its client IP to supported DoH resolvers and other users’ IDPs (for example, if a user who does not have an IDP is verifying another user’s attestation from Okta, their requests through the proxy would hide the client IP from Cloudflare and Okta). As previously described, if the client has a proxy configured, its proxy’s IP address may be revealed to the target domain. The concrete properties users obtain when leveraging IDP attestations depend on the specific application. For example, in an E2EE meeting (Section 7.10), users are able to confirm that their meeting partners belong to a specific account (identified by a domain they know) even if the users have never previously met. Meeting hosts can leverage attestations to prevent MitM attacks without manually checking security codes. We discuss how attestations are leveraged in E2EE Zoom Meetings in Section 7.10, and plan to extend support to other products in the future.