{"action":"created","issue":{"url":"https://api.github.com/repos/mozilla/fxa/issues/28","labels_url":"https://api.github.com/repos/mozilla/fxa/issues/28/labels{/name}","comments_url":"https://api.github.com/repos/mozilla/fxa/issues/28/comments","events_url":"https://api.github.com/repos/mozilla/fxa/issues/28/events","html_url":"https://github.com/mozilla/fxa/issues/28","id":96371383,"number":28,"title":"Using kA for Sync","user":{"login":"dannycoates","id":87619,"avatar_url":"https://avatars.githubusercontent.com/u/87619?v=3","gravatar_id":"","url":"https://api.github.com/users/dannycoates","html_url":"https://github.com/dannycoates","followers_url":"https://api.github.com/users/dannycoates/followers","following_url":"https://api.github.com/users/dannycoates/following{/other_user}","gists_url":"https://api.github.com/users/dannycoates/gists{/gist_id}","starred_url":"https://api.github.com/users/dannycoates/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dannycoates/subscriptions","organizations_url":"https://api.github.com/users/dannycoates/orgs","repos_url":"https://api.github.com/users/dannycoates/repos","events_url":"https://api.github.com/users/dannycoates/events{/privacy}","received_events_url":"https://api.github.com/users/dannycoates/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":7,"created_at":"2015-07-21T17:25:02Z","updated_at":"2015-07-23T22:31:26Z","closed_at":null,"body":"\r\nGoals:\r\n- compatible with existing stable Firefox\r\n- allow users to choose sync key strength\r\n\r\nIn order to be compatible with stable desktop I propose we manage key preference from the server an leave the browser code as is. The new meaning of kB in browser code would essentially be \"syncKey\" with no notion of B-ness or A-ness. Unfortunately, we can't retroactively change the name. Currently, wrapKb is mixed with unwrapBKey to obtain kB, so if a user selected kA we need to make unwrapBKey ^ wrapKb == kA. Fortunately (to the best of my knowledge) on desktop, unwrapBKey is only supplied to the browser by content-server hosted code so we can deploy new code to set unwrapBKey based on preference. I don't yet know how Fennec acquires unwrapBKey...\r\n\r\nIf we have a user preference named syncKey, overriding unwrapBKey becomes:\r\n```js\r\nif (syncKey === 'kA') {\r\n  unwrapBKey = wrapKb ^ kA\r\n}\r\n```\r\nThe tricky part (though I haven't looked yet) may be in the timing of when unwrapBKey is set. This way requires us to have the keys available first whereas the traditional way doesn't require any key data, just the user's password.\r\n\r\nAs far as auth-server is concerned I think this only requires remembering the new preference and including it in the key bundle.\r\n\r\nThe content-server will need UI for the preference and to handle unwrapBKey."},"comment":{"url":"https://api.github.com/repos/mozilla/fxa/issues/comments/124255800","html_url":"https://github.com/mozilla/fxa/issues/28#issuecomment-124255800","issue_url":"https://api.github.com/repos/mozilla/fxa/issues/28","id":124255800,"user":{"login":"dannycoates","id":87619,"avatar_url":"https://avatars.githubusercontent.com/u/87619?v=3","gravatar_id":"","url":"https://api.github.com/users/dannycoates","html_url":"https://github.com/dannycoates","followers_url":"https://api.github.com/users/dannycoates/followers","following_url":"https://api.github.com/users/dannycoates/following{/other_user}","gists_url":"https://api.github.com/users/dannycoates/gists{/gist_id}","starred_url":"https://api.github.com/users/dannycoates/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/dannycoates/subscriptions","organizations_url":"https://api.github.com/users/dannycoates/orgs","repos_url":"https://api.github.com/users/dannycoates/repos","events_url":"https://api.github.com/users/dannycoates/events{/privacy}","received_events_url":"https://api.github.com/users/dannycoates/received_events","type":"User","site_admin":false},"created_at":"2015-07-23T22:31:26Z","updated_at":"2015-07-23T22:31:26Z","body":"To me the primary benefit of this approach is that it lets us *transition* to a more explicit key management model where which key is used for a given purpose is not encoded directly in code, while both maintaining the current semantics of kA and kB, and allowing stable desktop Firefox to make use of either preferred key during and after the transition.\r\n\r\nHacking `unwrapBKey` is not the long term solution but it allows us to use kA before desktop can switch to a new API. Future Firefox should be aware of the pref and use the proper key directly.\r\n\r\n> If you request keys via the old key-fetch API, you get a wrapKb that's all zeros and fxa-content-server tells you that unwrapBKey is equal to kA.\r\n\r\nThis sounds functionally equivalent to my proposal, but special cases wrapKb and unwrapBKey based on the pref. My opinion is to only change the one that's not tied to the db so we don't need special logic in keyFetchToken generation.\r\n\r\n> I'm getting a bad feeling about the short-term-convenience vs long-term-complexity tradeoffs of this approach\r\n\r\nI'm interested in your feelings about long-term-complexity, because I don't see it. I see the complexity as being exclusively in the short term and getting phased out with new APIs.\r\n"}}