User:Fmarier/FxASyncPairing

User stories / audience

Here are the reasons why users want pairing:

As a forgetful user, I want to sync my things without having to pick a password.
As an impatient user, I want to connect my phone to my laptop without having to go through email verification or having to type anything on my phone.
As a user of Marketplace, I need to type my FxA password often on multiple devices and so my password may not be strong enough to protect my Sync data, which is a lot more personal than my purchase history.
As a privacy nerd, I only want to store my data on Mozilla's servers if it's encrypted using a full-strength key that never transits through an intermediate service, even if it means jumping through a few hoops.

The first two would likely involve big changes in how Firefox Accounts currently works and the assumptions it makes. A larger discussion needs to happen before we could prototype a solution for these stories. The last story would only address the needs of a small percentage of our users and so in the interest of increasing security for a large percentage of Firefox users, we will consider #3 to be our target audience.

Out of scope

Some of the following things are interesting but currently out of scope:

removing the need for a password in Firefox Accounts
allowing unverified emails in FxA
recovery of Sync data if one loses all devices and forgets password (i.e. class A data)
escrow of full strength keys to protect against device loss and improper backup practices (e.g. trusted third party or social escrow)
moving Content Server payloads to the client or validating these payloads (i.e. to prevent the delivery of vulnerable code by the server)

Pairing mechanisms

Here are the 4 key exchange mechanisms that have been considered to copy the full-strength key (required by user story #3) from the device that generated it to another:

0-bit pairing: Once a user has logged into their Firefox account on both devices, the class-B keys are used to authenticate a key-agreement protocol. The old device must ask the user for approval, then the full-strength key is pushed to the new device.
Manual key entry: Users can view or download the key on one device and either type it back onto the second device or import it from a file.
J-PAKE: This is the pairing mechanism that was used in Sync 1.1. Pairing is initiated on the first device which displays an ephemeral code. That code must be entered on the second device. No need to type in an email address, all that's needed on the second device is the code.
Barcode: A way to exchange data from a device to a mobile phone equipped with a camera. There is no need to type anything since the barcode (most likely a 2D barcode or QR code) includes everything needed.

Here's a comparison of these mechanisms:

Pairing mechanism	Desktop-to-Desktop [1]	Desktop-to-Mobile	Desktop-to-Laptop	Mobile-to-Desktop	Mobile-to-Mobile	Mobile-to-Laptop	Laptop-to-Desktop	Laptop-to-Mobile	Laptop-to-Laptop	Fully kC compliant	Fully backed up [6]
Current FxA Sync	yes	yes	yes	yes	yes	yes	yes	yes	yes	no	yes [7]
0-bit pairing	no	yes	yes	yes	yes	yes	yes	yes	yes	meh [4]	no
Manual key entry	yes	meh [2]	yes	meh [3]	meh [2]	meh [3]	yes	meh [2]	yes	yes	yes
J-PAKE	no	yes	yes	yes	yes	yes	yes	yes	yes	yes	no
Barcode	no	YES!	meh [5]	no	YES!	meh [5]	no	YES!	meh [5]	yes	no

requires time shifting since devices may not be in physical proximity
typing on mobile is not fun
securely copying files out of a mobile is hard
using the "kB channel" to copy kC reduces the strength of the key
using a laptop camera to scan a QR code is hard
user can recover their data after losing all devices
users lose their data if they forget their password & lose all devices

In order to cover all different types of pairing and to simplify the most common pairing case (desktop/laptop to mobile), we propose implementing: J-PAKE, manual key entry and barcodes.