Services/Sync/KeyWrappingOptions

Problem to solve

STB (Signin to Browser) currently depends on a wrapped key. Sync does not. What options do we have for supporting both options? It's also a new system, with (at least) new auth and crypto, so what are our migration/cutover options?

Competitive Solutions

gps did a comprehensive analysis of what's out there now: http://gregoryszorc.com/blog/2012/04/08/comparing-the-security-and-privacy-of-browser-syncing/

The biggest competitor we have is Chrome, who use a similar key-derivation scheme as is proposed, while also allowing a user-selected passphrase that is not tied to the Google account password.

Open Questions and Possible Answers

Can we have a flag day (in clients) where users must opt into STB instead of old-style Sync?

• Yes, with first STB release (Sync 1.1 is EOL once enough users have upgraded, likely not before Fx10 ESR EOL)
• Not in first STB release, Yes in some future release (Sync 1.1 and 2.0 auth options co-exist in parallel until sufficient migration has taken place, and then we flag day)
• No, never (Sync creds/UX must exist forever in parallel)

If we are not having a flag day in clients at launch, how can we support that (second and third options above)?

• Completely independent services, Firefox offers choice between STB/Persona and Firefox Sync
  • Followup: allow new user signups for FxSync?
  • Followup: Can I opt into the non-Sync parts of STB and retain old sync?
• Support HTTP basic auth to token server, which talks to existing LDAP accounts
  • J-PAKE and all other UX exists as-is, change is invisible to user
  • Interoperable with older clients as LDAP remains source of truth for basic auth users
  • All client code post-auth/obtaining keys is identical
  • This is a good solution for 3rd party installs
  • Very difficult to "join" a sync account with a BID account
• Silently create Persona accounts for existing users, and tie token server to LDAP source of truth for those users
  • Open question around key management
  • Interoperable with older clients
  • Many Sync users have very weak passwords
  • There might be legal issues b/c of terms of service
  • Security questions around accessing LDAP accounts without passwords

Do we want to support "the 2%" by providing user-only crypto secrets without password-based wrapping and/or server-side storage as a part of STB?

• Yes, in-product option
• Yes, via add-on only
  • (more below on both of these)
• No, we will continue to offer Firefox Sync for those users
• No, but the client will retain old-style sync to support 3rd-party servers
• No, those users are not supported by us in any form

If we provide an option for a user-only secret in STB (first two options below):

• What is the scope of that secret (choose 1)?
  • Persona UK (User Key) is not wrapped and stored on Persona service, all services that utilize key wrapping require users to provide their UK
  • Sync Key is not wrapped by User Key, all other services that are part of STB must provide their own opt-out or only use key wrapping

• How will users transport keys (choose as many as you want)?
  • We will continue to support J-PAKE credential exchange in product
  • We will support manual entry in product
  • We will provide PKCS12-alike key backups with passphrases for user transport
  • We will provide temporary key escrow on BrowserID or Sync servers or other centralized storage server
  • We will provide hooks in the API to import and export keys and add-ons will provide transport options