Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Fwd: Sync in 2012: Persona Integration
28 views
Skip to first unread message
Peter Pin-Guang Chen
Apr 12, 2012, 1:01:09 AM4/12/12
to MozTW, dev-gen...@lists.mozilla.org, mozilla.community.taiwan
Dears,
如果你對 Firefox 的同步功能 Firefox Sync (未來會改叫 Persona Sync?)
在現在的作法以及未來會有的調整方式有興趣的話，可以 follow 一下這系列文章以及後續的討論串。
有什麼問題或意見的話可以直接到 dev-planning 回信給 Greg，也可在這裡回覆討論，我會從 l10n team
的角度看看有什麼方式可以讓它變得更好 :)
------------------------------------------------------------------------------------------
Peter Pin-Guang Chen (petercpg)
Chinese (Traditional) [zh-TW] Localization Project Coordinator
Mozilla Taiwan Community (MozTW) http://moztw.org
---------- Forwarded message ----------
From: Gregory Szorc <g...@mozilla.com>
Date: 2012/4/12
Subject: Sync in 2012: Persona Integration
To: dev-pl...@lists.mozilla.org
tl;dr Drastic changes to Sync have been proposed, including to the
end-to-end security model. A series of posts will detail the main areas for
change and call for feedback to help shape these changes. This specific
post details how the security model of Sync will change to support
integration with Persona.
---
2012 is shaping up to be a significant year for Sync! We have a number of
important decisions to make and would like to collect as much feedback as
possible to help shape the direction of this important feature.
The topic is split into multiple posts to make the discussion easier to
follow. This part focuses on integrating Sync with Persona (Persona is the
Mozilla instance of the BrowserID authentication protocol). But first, an
overview.
Context for Change
==================
The subjects in these posts are driven by a number of factors.
First, we have the user experience of Sync. It's hard to use. User studies
have shown that many people don't grok the Sync setup and pairing process
(especially the latter). This is partially a side-effect of the original
design of Sync, which placed security and user sovereignty over their data
as the main goals (more important than user experience).
Second, a new "sign in to the browser" feature is on the roadmap [1]. We
believe it is in the best interest of the majority of our users to have
Sync "just work" with that. Furthermore, we believe that "sign in to the
browser" without Sync isn't a very compelling feature.
Third, the Services team is working on the next version of the storage
service used by Sync — version 2.0 [2]. This version addresses a number of
deficiencies with the current 1.1 version of the server and is necessary to
provide a better feature.
Fourth, there are a number of warts in Sync's current implementation that
we have been itching to correct. Some of these are backwards incompatible
and so we have been holding off until an opportunity arises to address them
without additional impact.
Persona Integration
===================
The solution we propose to address the user experience deficiencies and
integration with "sign in to the browser" is integration with Persona
(BrowserID). Persona integration will involve two separate, but related
changes: how users authenticate with the Sync server and how the root Sync
encryption key is managed.
Sync Today
==========
To better understand the proposal, it will help to have an understanding of
how Sync works today.
When you initially sign-up for Sync, you create a Mozilla Services account
by specifying an email address and password. We call this username and
password your Sync credentials. All communication with the Sync server is
secured via TLS (HTTPS). All HTTP requests use HTTP Basic Auth with your
Sync credentials to prevent unauthorized access to your server-stored data.
This methodology should be familiar to anyone who has had experience
running an HTTP server.
Now, it gets more complicated.
When you create your Sync account, your machine generates a
cryptographically-secure 128-bit random number. We refer to this 128-bit
random number as your Sync Key.
We use HKDF [3] on your Sync Key to derive two 256-bit keys. One of these
keys is used for symmetric AES-256 encryption; the other for HMAC-SHA256
message verification. I will spare you from all the low-level details. Just
know that *all* user data is encrypted *locally* with this key pair (or
similar full-entropy 256-bit key pairs) then uploaded to the Sync server.
All encrypted data on the server is chained to your 128-bit Sync Key. All
encrypted data on the server is encrypted with full-entropy 256-bit keys.
Full technical details are available at [4].
Your Sync Key or the derived pair of 256-bit keys is *never* transmitted to
the Sync server or Mozilla (at least in any form they can read — more
later). This means that the Sync server can withstand a full data breach
with only minimal metadata being compromised. The most someone with the
data could ascertain would be modified times, record counts, sizes, access
times, etc. The unencrypted IDs of records on the server are randomly
generated on the client, so even they can't be used to determine what a
specific records corresponds to. Cracking your data would require a
brute-force attack over 128 bits of permutations. This is statistically
impossible.
In short, you need the 128-bit Sync Key to read data stored on the server.
The Sync Key is 128 bits for historical reasons. In the old days of Sync,
people needed to manually type their Sync Key to pair devices. We use a
modified base32 encoding for Sync Key presentation purposes (to prevent
character confusion and so there are no capital characters to worry about).
This requires 26 characters. If we used a 256 bit key, that would require
52 characters. And, if we wanted a pair of 256 bit keys, that would require
104 characters! 26 characters was the most we wanted to ask our users to
type, so we have a 128-bit root key.
We thought we could do better on the user experience front, so we
introduced J-PAKE for the pairing setup [5]. With J-PAKE, the user is
presented 12 random characters. These 12 characters (a one-time transfer
code) are entered on another device and the two machines create an
encrypted channel between them (through a central brokering server). The
Sync credentials, Sync Key, and server info are transmitted to the other
client and the new device is paired. Even though data passes through a
central brokering server (which is typically operated by Mozilla), data is
encrypted end-to-end, so even the server can't see what's passing through.
i.e., the Sync Key is not made available to any other party.
With J-PAKE, the user needs to enter only 12 characters instead of 26. The
Sync Key is also hidden from the user (which is good, because we find that
some users do things like email the Sync Key or upload it to an unencrypted
cloud storage service, undermining the security of Sync in the process).
One downside is users need to have simultaneous access to both devices for
the pairing. This isn't always possible. Also, people are confused by it.
They just don't understand what is going on. Passwords they get. One-time
pairing sequences, not so much. Of course, users still have the option to
transpose the key manually (available behind an advanced settings link).
When we switched to J-PAKE, we could have gotten rid of the 128-bit Sync
Key and replaced it with a pair of 256-bit keys. However, we deemed the
engineering effort was too high to accomodate our schedule at the time.
And, having manual key entry as a fall-back was nice-to-have (for
connecting two devices that aren't both in front of you, for example). And,
a 128-bit key was backwards compatible. And, 128 bits of entropy for a root
key was still pretty good. So, we stuck with a 128-bit Sync Key with
derivation to a pair of 256-bit keys.
Now that you have a basic overview of how Sync works, let's talk about the
proposed changes.
Persona for Authentication
==========================
For Persona integration, we would replace Mozilla Services accounts with
Persona. This means that the Sync server will authenticate clients with
BrowserID assertions, not HTTP Basic Auth with your Mozilla Services
credentials. If you are curious about the implementation details, see [6].
This change would mean that users will need a Persona account to use Sync.
For existing Sync users, we'll likely have some kind of UI in the browser
to prompt you to create a Persona account , possibly with the same email
address used for the Mozilla Services account — we haven't finalized
details yet.
Proposal for Sync Key Management
==============================**==
The larger change for Persona integration would be how your Sync Key is
managed.
First, we propose doing away with the 128-bit Sync Key and HKDF derivation
of a pair of 256-bit keys. Replacing it will be a pair of
randomly-generated 256-bit keys. (We've wanted to do this for a while.)
This effectively increases the maximum achievable cryptographic security of
Sync since we would be using true 256-bit keys rather than those derived
from a 128-bit key. More details are available in part 2 of this post.
The second change for Persona integration deals with how the Sync Key is
secured and stored. The proposal is for Sync to leverage a "key wrapping"
facility provided by Persona. Full details about Persona key wrapping are
available at [7]. In summary, your Persona account has associated with it a
pair of randomly-generated keys (just like Sync). This key pair is called
the [Persona] User Key, or UK. Persona provides APIs that can be used to
"wrap" and "unwrap" arbitrary pieces of data. This is just a convenient way
of saying that Persona encrypts and signs (or verifies and decrypts) data
with the UK.
When you create a Sync account, the Sync client would generate a random key
(just like today). It would then call a Persona API on the client to "wrap"
your Sync Key. Persona would return a blob of data that is
wrapped/encrypted/signed with the UK. The wrapped Sync Key would then be
uploaded to the Sync server.
When a new Sync client needs to access your data, it would log in to
Persona, fetch the wrapped Sync Key from the Sync server, then hand off the
wrapped data to Persona and get back the original Sync Key. The Sync client
would then proceed like normal. No device pairing. No need to have two
devices in physical proximity. No additional UI. You just log in to Persona
and your Sync-managed data is magically available.
So far, the security model is isomorphic to the world without Persona: we
have keys rooted to a pair of randomly generated 256-bit keys. The only
difference is we have an extra layer of key chaining and the next link (the
Sync Key) is also stored encrypted on the Sync server. No big deal.
This means we push the problem of managing the root key out of Sync and
into Persona. And management of the Persona UK is where things get
interesting again.
Persona User Key Management
===========================
In order to facilitate Sync "just working" after logging in to Persona, the
UK will need to be stored centrally. If the UK is not stored centrally nor
always available, you are back to Sync's usability issues around pairing:
you'd need some way to transmit the UK between clients.
So, how do we plan to store the UK centrally? The general plan is to
encrypt the UK on the client before it is uploaded to the Persona server
for storage. How, exactly, we're not sure yet.
The minimum proposal is to use PBKDF2 of your Persona login credentials
(i.e., your Persona password) to derive a a password key (PWK). Then, we'd
use the PWK to encrypt and sign the UK before uploading it to the server.
Any client with the Persona credentials could download the encrypted UK
from the Persona server and decrypt it with the PWK. On top of that, the
current proposal is for Mozilla to be the only entity within the BrowserID
ecosystem that stores encrypted UKs. Even IdP's (which you trust to issue
credentials to you) wouldn't have this information.
When we consider this proposal with Sync, it means that everything would
effectively be chained to a user-supplied password, not a 128-bit Sync Key.
Trying to Appease Everyone
==========================
Usability and security are often at odds with each other and different
people prefer to sit at specific points in this spectrum. No matter what
decision we make, we understand it will be impossible to satisfy everyone.
Even today, with Sync's security model where the server operators (Mozilla
for the default Sync server in Firefox) only have access to limited
metadata (common to just about every hosted service), there are people who
insist on running their own Sync server for privacy and/or security reasons
(see [8] for instructions for running your own server). There's nothing
wrong with doing that or holding that belief. And, it should not be
discouraged.
The general rule is we tailor Firefox to 80% of the users. And today, 80%
do not grok Sync's setup process. Since Firefox is expanding to more mobile
devices, where Sync is a must-have feature (for many at least) and since we
wish for people to be able to log in to a "cold" browser and have access to
their data, we need to change Sync so it is usable without additional setup
complexity. This, unfortunately, means reducing the end-to-end security in
the /default/ case.
I want to explicitly state that even though the end-to-end security would
be weakened, it would still be pretty good. We're not talking about storing
your data unencrypted or making your encryption keys easily available. We
feel the end state of this shift is still well within the acceptable range
of most people. Only those in the "more paranoid" end of the spectrum would
"lose coverage."
It would be hard to let these security-minded people go. And, I hope it
doesn't come to that. Above, I mentioned a "default case" for the security
settings. I say "default case" because I (and many others) insist that
users who want to sit at the more secure end of the security spectrum have
that choice, especially since that is where they are now. I (and many
others) believe it would be ethically wrong to ship a Firefox that
permanently eroded Sync's data security protections on which people have
come to rely. To these people who love Sync today because in a world where
your user data is often uploaded unencrypted and used for behavioral
analytics ("you are the product"), Firefox Sync's model of strong
client-side encryption stands out from the crowd and is rewarded with your
patronage: you deserve continued support for the existing (if not better)
level of security.
I (and a lot of other people), are committed to allowing Sync users to
maintain the current level of security while we make the transition to
Persona. I'm not sure exactly how we're going to do that yet. Maybe there
are about:config-only preferences to prevent your Sync Key from being
wrapped with your Persona UK. Maybe Persona has options to control the
minimum encryption levels for the UK. Maybe UK escrow can be disabled.
Maybe we keep the J-PAKE server running and have the Sync pairing UI
somewhere in an advanced settings dialog. Maybe we could use J-PAKE for the
UK. Maybe we require a second set of credentials to unlock the UK. Maybe
accounts have multiple UKs with different security settings. Maybe we give
users the choice between usability and security when initially configuring
Sync or UK management. I don't know yet.
What I can tell you is that a lot of people are thinking about solutions.
And at this point, everything (within reason) is on the table.
We would like to foster a discussion on this subject. If you have any ideas
or opinions, please speak up!
More Secure than PBKDF2
=======================
Above, I mentioned that the current minimum security proposal is for the
Persona UK to be encrypted using a PBKDF2-derived key from your Persona
password. While this is certainly more secure than using no client-side
encryption, it isn't as good as we would like.
A number of people have been losing sleep over how we can do better. Brian
Warner is probably the most sleep-deprived of the lot. His first proposal
is at [9]. If you have an interest in making Persona's key wrapping
facility as secure as possible, please look at his work.
If you are a security or crypto expert, this is a particular area where
your input would be most valuable. Please dump your brain so we can make
the best decision for our users.
Conclusion
==========
Switching Sync to use Persona to support log in to the browser [through
passphrases] — which will enable a better web experience — will involve
weakening Sync's end-to-end security model.
We are looking for input to help minimize the security tradeoff being made
with the transition to better usability. We are also keen to retain support
for the existing level of end-to-end security and would like to foster a
discussion around the best ways to accomplish this.
Happy syncing,
Gregory Szorc
Firefox Sync Engineer
g...@mozilla.com
[1] https://wiki.mozilla.org/**Identity/Features/Sign_into_**the_browser<https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser>
[2] http://docs.services.mozilla.**com/storage/apis-2.0.html<http://docs.services.mozilla.com/storage/apis-2.0.html>
[3] https://tools.ietf.org/html/**rfc5869<https://tools.ietf.org/html/rfc5869>
[4] http://docs.services.mozilla.**com/sync/storageformat5.html<http://docs.services.mozilla.com/sync/storageformat5.html>
[5] http://docs.services.mozilla.**com/keyexchange/index.html<http://docs.services.mozilla.com/keyexchange/index.html>
[6] http://docs.services.mozilla.**com/token/index.html<http://docs.services.mozilla.com/token/index.html>
[7] https://wiki.mozilla.org/**BrowserID_Key_Wrapping<https://wiki.mozilla.org/BrowserID_Key_Wrapping>
[8] https://docs.services.mozilla.**com/<https://docs.services.mozilla.com/>
[9] https://wiki.mozilla.org/**Identity/CryptoIdeas/01-PBKDF-**scrypt<https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt>
______________________________**_________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
如果你對 Firefox 的同步功能 Firefox Sync (未來會改叫 Persona Sync?)
在現在的作法以及未來會有的調整方式有興趣的話，可以 follow 一下這系列文章以及後續的討論串。
有什麼問題或意見的話可以直接到 dev-planning 回信給 Greg，也可在這裡回覆討論，我會從 l10n team
的角度看看有什麼方式可以讓它變得更好 :)
------------------------------------------------------------------------------------------
Peter Pin-Guang Chen (petercpg)
Chinese (Traditional) [zh-TW] Localization Project Coordinator
Mozilla Taiwan Community (MozTW) http://moztw.org
---------- Forwarded message ----------
From: Gregory Szorc <g...@mozilla.com>
Date: 2012/4/12
Subject: Sync in 2012: Persona Integration
To: dev-pl...@lists.mozilla.org
tl;dr Drastic changes to Sync have been proposed, including to the
end-to-end security model. A series of posts will detail the main areas for
change and call for feedback to help shape these changes. This specific
post details how the security model of Sync will change to support
integration with Persona.
---
2012 is shaping up to be a significant year for Sync! We have a number of
important decisions to make and would like to collect as much feedback as
possible to help shape the direction of this important feature.
The topic is split into multiple posts to make the discussion easier to
follow. This part focuses on integrating Sync with Persona (Persona is the
Mozilla instance of the BrowserID authentication protocol). But first, an
overview.
Context for Change
==================
The subjects in these posts are driven by a number of factors.
First, we have the user experience of Sync. It's hard to use. User studies
have shown that many people don't grok the Sync setup and pairing process
(especially the latter). This is partially a side-effect of the original
design of Sync, which placed security and user sovereignty over their data
as the main goals (more important than user experience).
Second, a new "sign in to the browser" feature is on the roadmap [1]. We
believe it is in the best interest of the majority of our users to have
Sync "just work" with that. Furthermore, we believe that "sign in to the
browser" without Sync isn't a very compelling feature.
Third, the Services team is working on the next version of the storage
service used by Sync — version 2.0 [2]. This version addresses a number of
deficiencies with the current 1.1 version of the server and is necessary to
provide a better feature.
Fourth, there are a number of warts in Sync's current implementation that
we have been itching to correct. Some of these are backwards incompatible
and so we have been holding off until an opportunity arises to address them
without additional impact.
Persona Integration
===================
The solution we propose to address the user experience deficiencies and
integration with "sign in to the browser" is integration with Persona
(BrowserID). Persona integration will involve two separate, but related
changes: how users authenticate with the Sync server and how the root Sync
encryption key is managed.
Sync Today
==========
To better understand the proposal, it will help to have an understanding of
how Sync works today.
When you initially sign-up for Sync, you create a Mozilla Services account
by specifying an email address and password. We call this username and
password your Sync credentials. All communication with the Sync server is
secured via TLS (HTTPS). All HTTP requests use HTTP Basic Auth with your
Sync credentials to prevent unauthorized access to your server-stored data.
This methodology should be familiar to anyone who has had experience
running an HTTP server.
Now, it gets more complicated.
When you create your Sync account, your machine generates a
cryptographically-secure 128-bit random number. We refer to this 128-bit
random number as your Sync Key.
We use HKDF [3] on your Sync Key to derive two 256-bit keys. One of these
keys is used for symmetric AES-256 encryption; the other for HMAC-SHA256
message verification. I will spare you from all the low-level details. Just
know that *all* user data is encrypted *locally* with this key pair (or
similar full-entropy 256-bit key pairs) then uploaded to the Sync server.
All encrypted data on the server is chained to your 128-bit Sync Key. All
encrypted data on the server is encrypted with full-entropy 256-bit keys.
Full technical details are available at [4].
Your Sync Key or the derived pair of 256-bit keys is *never* transmitted to
the Sync server or Mozilla (at least in any form they can read — more
later). This means that the Sync server can withstand a full data breach
with only minimal metadata being compromised. The most someone with the
data could ascertain would be modified times, record counts, sizes, access
times, etc. The unencrypted IDs of records on the server are randomly
generated on the client, so even they can't be used to determine what a
specific records corresponds to. Cracking your data would require a
brute-force attack over 128 bits of permutations. This is statistically
impossible.
In short, you need the 128-bit Sync Key to read data stored on the server.
The Sync Key is 128 bits for historical reasons. In the old days of Sync,
people needed to manually type their Sync Key to pair devices. We use a
modified base32 encoding for Sync Key presentation purposes (to prevent
character confusion and so there are no capital characters to worry about).
This requires 26 characters. If we used a 256 bit key, that would require
52 characters. And, if we wanted a pair of 256 bit keys, that would require
104 characters! 26 characters was the most we wanted to ask our users to
type, so we have a 128-bit root key.
We thought we could do better on the user experience front, so we
introduced J-PAKE for the pairing setup [5]. With J-PAKE, the user is
presented 12 random characters. These 12 characters (a one-time transfer
code) are entered on another device and the two machines create an
encrypted channel between them (through a central brokering server). The
Sync credentials, Sync Key, and server info are transmitted to the other
client and the new device is paired. Even though data passes through a
central brokering server (which is typically operated by Mozilla), data is
encrypted end-to-end, so even the server can't see what's passing through.
i.e., the Sync Key is not made available to any other party.
With J-PAKE, the user needs to enter only 12 characters instead of 26. The
Sync Key is also hidden from the user (which is good, because we find that
some users do things like email the Sync Key or upload it to an unencrypted
cloud storage service, undermining the security of Sync in the process).
One downside is users need to have simultaneous access to both devices for
the pairing. This isn't always possible. Also, people are confused by it.
They just don't understand what is going on. Passwords they get. One-time
pairing sequences, not so much. Of course, users still have the option to
transpose the key manually (available behind an advanced settings link).
When we switched to J-PAKE, we could have gotten rid of the 128-bit Sync
Key and replaced it with a pair of 256-bit keys. However, we deemed the
engineering effort was too high to accomodate our schedule at the time.
And, having manual key entry as a fall-back was nice-to-have (for
connecting two devices that aren't both in front of you, for example). And,
a 128-bit key was backwards compatible. And, 128 bits of entropy for a root
key was still pretty good. So, we stuck with a 128-bit Sync Key with
derivation to a pair of 256-bit keys.
Now that you have a basic overview of how Sync works, let's talk about the
proposed changes.
Persona for Authentication
==========================
For Persona integration, we would replace Mozilla Services accounts with
Persona. This means that the Sync server will authenticate clients with
BrowserID assertions, not HTTP Basic Auth with your Mozilla Services
credentials. If you are curious about the implementation details, see [6].
This change would mean that users will need a Persona account to use Sync.
For existing Sync users, we'll likely have some kind of UI in the browser
to prompt you to create a Persona account , possibly with the same email
address used for the Mozilla Services account — we haven't finalized
details yet.
Proposal for Sync Key Management
==============================**==
The larger change for Persona integration would be how your Sync Key is
managed.
First, we propose doing away with the 128-bit Sync Key and HKDF derivation
of a pair of 256-bit keys. Replacing it will be a pair of
randomly-generated 256-bit keys. (We've wanted to do this for a while.)
This effectively increases the maximum achievable cryptographic security of
Sync since we would be using true 256-bit keys rather than those derived
from a 128-bit key. More details are available in part 2 of this post.
The second change for Persona integration deals with how the Sync Key is
secured and stored. The proposal is for Sync to leverage a "key wrapping"
facility provided by Persona. Full details about Persona key wrapping are
available at [7]. In summary, your Persona account has associated with it a
pair of randomly-generated keys (just like Sync). This key pair is called
the [Persona] User Key, or UK. Persona provides APIs that can be used to
"wrap" and "unwrap" arbitrary pieces of data. This is just a convenient way
of saying that Persona encrypts and signs (or verifies and decrypts) data
with the UK.
When you create a Sync account, the Sync client would generate a random key
(just like today). It would then call a Persona API on the client to "wrap"
your Sync Key. Persona would return a blob of data that is
wrapped/encrypted/signed with the UK. The wrapped Sync Key would then be
uploaded to the Sync server.
When a new Sync client needs to access your data, it would log in to
Persona, fetch the wrapped Sync Key from the Sync server, then hand off the
wrapped data to Persona and get back the original Sync Key. The Sync client
would then proceed like normal. No device pairing. No need to have two
devices in physical proximity. No additional UI. You just log in to Persona
and your Sync-managed data is magically available.
So far, the security model is isomorphic to the world without Persona: we
have keys rooted to a pair of randomly generated 256-bit keys. The only
difference is we have an extra layer of key chaining and the next link (the
Sync Key) is also stored encrypted on the Sync server. No big deal.
This means we push the problem of managing the root key out of Sync and
into Persona. And management of the Persona UK is where things get
interesting again.
Persona User Key Management
===========================
In order to facilitate Sync "just working" after logging in to Persona, the
UK will need to be stored centrally. If the UK is not stored centrally nor
always available, you are back to Sync's usability issues around pairing:
you'd need some way to transmit the UK between clients.
So, how do we plan to store the UK centrally? The general plan is to
encrypt the UK on the client before it is uploaded to the Persona server
for storage. How, exactly, we're not sure yet.
The minimum proposal is to use PBKDF2 of your Persona login credentials
(i.e., your Persona password) to derive a a password key (PWK). Then, we'd
use the PWK to encrypt and sign the UK before uploading it to the server.
Any client with the Persona credentials could download the encrypted UK
from the Persona server and decrypt it with the PWK. On top of that, the
current proposal is for Mozilla to be the only entity within the BrowserID
ecosystem that stores encrypted UKs. Even IdP's (which you trust to issue
credentials to you) wouldn't have this information.
When we consider this proposal with Sync, it means that everything would
effectively be chained to a user-supplied password, not a 128-bit Sync Key.
Trying to Appease Everyone
==========================
Usability and security are often at odds with each other and different
people prefer to sit at specific points in this spectrum. No matter what
decision we make, we understand it will be impossible to satisfy everyone.
Even today, with Sync's security model where the server operators (Mozilla
for the default Sync server in Firefox) only have access to limited
metadata (common to just about every hosted service), there are people who
insist on running their own Sync server for privacy and/or security reasons
(see [8] for instructions for running your own server). There's nothing
wrong with doing that or holding that belief. And, it should not be
discouraged.
The general rule is we tailor Firefox to 80% of the users. And today, 80%
do not grok Sync's setup process. Since Firefox is expanding to more mobile
devices, where Sync is a must-have feature (for many at least) and since we
wish for people to be able to log in to a "cold" browser and have access to
their data, we need to change Sync so it is usable without additional setup
complexity. This, unfortunately, means reducing the end-to-end security in
the /default/ case.
I want to explicitly state that even though the end-to-end security would
be weakened, it would still be pretty good. We're not talking about storing
your data unencrypted or making your encryption keys easily available. We
feel the end state of this shift is still well within the acceptable range
of most people. Only those in the "more paranoid" end of the spectrum would
"lose coverage."
It would be hard to let these security-minded people go. And, I hope it
doesn't come to that. Above, I mentioned a "default case" for the security
settings. I say "default case" because I (and many others) insist that
users who want to sit at the more secure end of the security spectrum have
that choice, especially since that is where they are now. I (and many
others) believe it would be ethically wrong to ship a Firefox that
permanently eroded Sync's data security protections on which people have
come to rely. To these people who love Sync today because in a world where
your user data is often uploaded unencrypted and used for behavioral
analytics ("you are the product"), Firefox Sync's model of strong
client-side encryption stands out from the crowd and is rewarded with your
patronage: you deserve continued support for the existing (if not better)
level of security.
I (and a lot of other people), are committed to allowing Sync users to
maintain the current level of security while we make the transition to
Persona. I'm not sure exactly how we're going to do that yet. Maybe there
are about:config-only preferences to prevent your Sync Key from being
wrapped with your Persona UK. Maybe Persona has options to control the
minimum encryption levels for the UK. Maybe UK escrow can be disabled.
Maybe we keep the J-PAKE server running and have the Sync pairing UI
somewhere in an advanced settings dialog. Maybe we could use J-PAKE for the
UK. Maybe we require a second set of credentials to unlock the UK. Maybe
accounts have multiple UKs with different security settings. Maybe we give
users the choice between usability and security when initially configuring
Sync or UK management. I don't know yet.
What I can tell you is that a lot of people are thinking about solutions.
And at this point, everything (within reason) is on the table.
We would like to foster a discussion on this subject. If you have any ideas
or opinions, please speak up!
More Secure than PBKDF2
=======================
Above, I mentioned that the current minimum security proposal is for the
Persona UK to be encrypted using a PBKDF2-derived key from your Persona
password. While this is certainly more secure than using no client-side
encryption, it isn't as good as we would like.
A number of people have been losing sleep over how we can do better. Brian
Warner is probably the most sleep-deprived of the lot. His first proposal
is at [9]. If you have an interest in making Persona's key wrapping
facility as secure as possible, please look at his work.
If you are a security or crypto expert, this is a particular area where
your input would be most valuable. Please dump your brain so we can make
the best decision for our users.
Conclusion
==========
Switching Sync to use Persona to support log in to the browser [through
passphrases] — which will enable a better web experience — will involve
weakening Sync's end-to-end security model.
We are looking for input to help minimize the security tradeoff being made
with the transition to better usability. We are also keen to retain support
for the existing level of end-to-end security and would like to foster a
discussion around the best ways to accomplish this.
Happy syncing,
Gregory Szorc
Firefox Sync Engineer
g...@mozilla.com
[1] https://wiki.mozilla.org/**Identity/Features/Sign_into_**the_browser<https://wiki.mozilla.org/Identity/Features/Sign_into_the_browser>
[2] http://docs.services.mozilla.**com/storage/apis-2.0.html<http://docs.services.mozilla.com/storage/apis-2.0.html>
[3] https://tools.ietf.org/html/**rfc5869<https://tools.ietf.org/html/rfc5869>
[4] http://docs.services.mozilla.**com/sync/storageformat5.html<http://docs.services.mozilla.com/sync/storageformat5.html>
[5] http://docs.services.mozilla.**com/keyexchange/index.html<http://docs.services.mozilla.com/keyexchange/index.html>
[6] http://docs.services.mozilla.**com/token/index.html<http://docs.services.mozilla.com/token/index.html>
[7] https://wiki.mozilla.org/**BrowserID_Key_Wrapping<https://wiki.mozilla.org/BrowserID_Key_Wrapping>
[8] https://docs.services.mozilla.**com/<https://docs.services.mozilla.com/>
[9] https://wiki.mozilla.org/**Identity/CryptoIdeas/01-PBKDF-**scrypt<https://wiki.mozilla.org/Identity/CryptoIdeas/01-PBKDF-scrypt>
______________________________**_________________
dev-planning mailing list
dev-pl...@lists.mozilla.org
https://lists.mozilla.org/**listinfo/dev-planning<https://lists.mozilla.org/listinfo/dev-planning>
0 new messages