[Cryptography] Zoom publishes draft cryptographic design for end-to-end encryption

[John Gilmore]

Blog post:

  https://blog.zoom.us/wordpress/2020/05/22/zoom-publishes-draft-design-of-end-to-end-encryption-offering/

Draft design:

  https://github.com/zoom/zoom-e2e-whitepaper/raw/master/zoom_e2e.pdf

  E2E Encryption for Zoom Meetings

  Josh Blum, Simon Booth, Oded Gal, Maxwell Krohn, Karan Lyons, Antonio
  Marcedone, Mike Maxim, Merry Ember Mou, Jack O’Connor, Miles Steele,
  Matthew Green(*), Lea Kissner, and Alex Stamos(**)

  Zoom Video Communications
  * Johns Hopkins University
  ** Stanford University
  May 22, 2020
  Version 1

  Introduction
  
  Hundreds of millions of participants join Zoom Meetings each day. They
  use Zoom to learn among classmates scattered by recent events, to
  connect with friends and family, to collab- orate with colleagues and,
  in some cases, to discuss critical matters of state. Zoom users
  deserve excellent security guarantees, and Zoom is working to provide
  these protections in a transparent and peer-reviewed process. This
  document, mindful of practical constraints, proposes major security
  and privacy upgrades for Zoom.

  We are at the beginning of a process of consultation with multiple
  stakeholders, including clients, cryptography experts, and civil
  society. As we receive feedback, we will update this document to
  reflect changes in roadmap and cryptographic design.

       ...

  This proposal lays out a long-term roadmap for E2E security in Zoom in
  four phases.  The first phase is an upgrade of the meeting key
  exchange protocol to use public-key cryptography, hiding all secret
  keys from the server. The next three phases harden the notion of a
  user’s identity—even across multiple devices—to help maintain server
  honesty in the key exchange and to give hosts better information when
  allowing or disallowing participation in a meeting. We provide the
  most detail for the earliest stages. We surmise that the specifics of
  later phases will change with more implementation and deployment
  experience.

       ...

  In an ideal world, all public key cryptographic operations could
  happen via Diffie-Hellman over Curve25519 [3], and EdDSA over Ed25519
  [4]. Relative to others, this curve and algorithm family have shown
  a consistent track record for resilience to common cryptographic
  attacks and implementation mistakes. These algorithms are currently in
  review for FIPS certification but, unfortunately, are not currently
  approved. Therefore, in some cases (like government uses that require
  FIPS certification) we must fall back to FIPS-approved algorithms,
  like ECDSA and ECDH over curve P-384. The protocol below has support
  for both algorithm families, and for now “doubles up” all public key
  operations. This technique eliminates error-prone branching. Once
  certification succeeds, we can safely “no-op” the operations over
  P-384.

	John
	
PS: I think I see a denial-of-service attack in section 3.7.3,
"Participant Join (Leader)".  If a second participant Mallory can post
an *invalid* signed binding claiming to be for a first participant Bob,
to the meeting's crypto bulletin board, then the leader's algorithm
aborts ("If verification fails, it aborts"), it doesn't post the
encrypted meeting key for Bob, and Bob is locked out of the meeting.
Fixing this may mean more tightly specifying how the "bulletin board"
works, as opposed to letting any participant post any message to it
at any time.