On 1/29/14 2:56 PM, Gene Wood wrote:
> Here's an operations-focused high level diagram of the user flow and
> network connections for Firefox Accounts and Sync
>
> https://wiki.mozilla.org/Identity/Firefox_Accounts#Architecture
>
> (second diagram)
Incidentally, who owns the first diagram? It st
On Jan 27, 2014, at 8:08 AM, Richard Newman wrote:
> As such, I would imagine that truncation here is fine, no? We're not really
> worried about collisions.
Truncating a good cryptographic hash function is safe, as long as you're still
happy with the remaining length. 16 bytes is enough to av
On 1/19/14 9:07 PM, Nick Alexander wrote:
> I don't think we need to take any action other than to update the
> onepw docs.
Updated.. please let me know if this should be better.
https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol#crypto-notes
""" There is no MAC on wrap(kB). If t
Hi folks.. next week, I'm giving a presentation on Firefox Sync and
Firefox Accounts, at the RealWorldCrypto conference in New York.
Today, in about 90 minutes (5pm PST), I'll be doing a dry-run of the
presentation on air.mozilla.org, from the SF 1st floor common area.
The presentation (which is
["To:" folks, please review]
ckarlof, nalexander, and myself had a meeting today to figure out what
should happen in Sync+FxAland when you change or reset your FxA account
password. We specifically cared about:
* resetting your account (new password, new encryption key) should *not*
result in
On 1/3/14 4:42 PM, Toby Elliott wrote:
> It also raises the question of what FxA Sync is under this model.
> Simply the same Sync backend, with FxA auth and key stretching
> replacing the secret key?
Yup. The FxA process ends with a (Persona) certificate, which gets
submitted to the tokenserver t
On 8/20/13 9:29 AM, Deb Richardson wrote:
Did you mean "those changes will apply to all of my *devices*"? So,
like, if I go into prefs on my phone and turn on "sync bookmarks"
(assuming it was was turned off before), my desktop will start
syncing bookmarks too?
Exactly. We discussed the option
On 8/20/13 7:57 AM, Deb Richardson wrote:
* As a user, I expect that my Sync settings will be applied
universally across all of my devices, so if I change which data
types I'm syncing while on my phone, those changes will apply to all
of my data types.
Did you mean "those changes will ap
On 8/12/13 6:55 AM, Lloyd Hilaiel wrote:
> What are the cons of reducing the security of recoverable class A data
> such that it could be accessed with a persona assertion asserting
> ownership of the email address stored in your account?
If I understand you correctly, the proposal is to replace
On 8/9/13 4:37 PM, Lloyd Hilaiel wrote:
> So I'd like to open a venting thread here. Let's capture once and for
> all the real, actual, user facing or implementation complexity
> downsides of implementing a new authentication flow and grafting it
> onto Sync 1.1.
I expect rnewman will express thi
On 8/9/13 3:15 PM, Lloyd Hilaiel wrote:
> 5. Security loss.
> (proposed) A: Authing from content is inevitable. Belief is there's no
> protocol sacrifices we need to make (full SRP from content is viable,
> stretching viable with native help). Phishing related concerns are all
> that remain mooted
On 8/9/13 3:15 PM, Lloyd Hilaiel wrote:
Chris and I talked about this a bit this afternoon. Some thoughts:
> 4. what is the extent of the content's responsibility? More than just
>auth gets sucky.
> A: It's just auth. More than just auth gets sucky. Preferences and
>mgmt are "native".
*
On 8/9/13 8:28 AM, Nick Alexander wrote:
> If we have the jelly do the auth dance (and return some set of tokens
> to the client?), then I think we're changing the TOFU + SRP security
> model of the auth server pretty significantly. But I suppose such
> issues are well enough understood from the P
On 8/7/13 6:13 PM, Chris Karlof wrote:
> In general, queue sync as described doesn't maintain much history for
> merging.
Yeah, I think there's a spectrum in which the more history we retain,
the better job of merging we can do. But I'm not convinced it's worth
storing a whole lot. We have to be
On 7/30/13 5:27 AM, Dale Harvey wrote:
> This looks like a good approach overall, its structured very similiar
> to how I want pouchdb architected eventually (writes always succeed,
> conflicts resolved in background, only the minimal revision history is
> stored), but it may be safer doing a writ
On 7/30/13 4:22 AM, Andreas Gal wrote:
> Also, as we discussed earlier, CouchDB's replication algorithm is not
> a perfect fit for our star-shaped nodes. Its meant for a more
> interconnected graph.
Yeah, it's kind of overkill for a star topology. We anticipate other
problems with relying on its
Chris and I have been sketching out what our queue-sync idea[1] would
look like when run over the CouchDB API. The rough initial writeup is here:
https://wiki.mozilla.org/Identity/CryptoIdeas/06-Queue-Sync-CouchDB
(with some even rougher notes on an etherpad[2]).
It lacks rigor, but should be
On 7/26/13 12:09 PM, Andreas Gal wrote:
> Which key approach we use is critical, however. Otherwise finding the
> dupes will be difficult in the client.
I was anticipating randomly-assigned-by-the-device keys for all records.
Then the code which merges downstream changes into the local datastore
18 matches
Mail list logo
