Using kA for Sync about fxa HOT 19 CLOSED

I forgot about propagating a pref change to existing sessions. How would that work?

from fxa.

allow users to choose sync key strength

Why? Why not always use maximum strength? 📶

from fxa.

@vladikoff If we're allowing people to sign in without a password (which is planned with the newest partner), then we won't have a kB to use for Sync. We could ask them for one later, or use a kA automatically.

from fxa.

The tricky part (though I haven't looked yet) may be in the timing of when unwrapBKey is set.

Yep. IIUC we currently message up to the browser all of { sessionToken, keyFetchToken, unwrapBKey } and it does its own key-fetch and unwrap. And since the keyFetchToken is single-use we can't just fetch the keys, calculate unwrapBKey, and then pass it on as before.

Is it an explicit goal that we give them the same bytes as kA? (By comparison, there was a previous proposal to to just pass up unwrapBKey="0"*32 and let them use the raw server-provided entropy in wrapKb).

I don't yet know how Fennec acquires unwrapBKey...

They do it by hand, deriving it directly from the quickStretchPwd calculated from user input. In the new p11 world they'll get it from the same place as desktop, but if the goal is "compatible with existing stable Firefox" then there's no much we can do for android.

from fxa.

Is it an explicit goal that we give them the same bytes as kA?

Good question. For our immediate use case where the user has no password we could easily get away with a null unwrapBKey, but in the general case don't we want the value of syncKey to be the same across password changes / resets if the pref implies kA? If so, I think syncKey === kA makes sense, otherwise it doesn't matter. What would the Sync experience be if the pref was kA and the user changed their password (wrapKb changes)?

there's no much we can do for android

I'm slightly less worried about changes to android given the sequence of how this will likely roll out. It is unfortunate that it won't "just work" though...

from fxa.

What would the Sync experience be if the pref was kA and the user changed their password (wrapKb changes)?

Yeah, that'd be terrible, changing wrapKb would mean they lose all their data still, getting the worst of both worlds. We could nuance that on the server by detecting if they've selected "recoverable sync" and not resetting their wrapKb, but we'd be adding a lot of implicitness and complexity.

Also, we have to remember that Hello is using (a derivative of) kB to encrypt some room/conversation data. I think this change would all "just work" for them as well, but we should consider it explicitly.

TBH, I'm getting a bad feeling about the short-term-convenience vs long-term-complexity tradeoffs of this approach, especially since we're handling security-critical stuff like keys. I wonder if we can change the balance by re-working how we handle keys on the auth server and providing a more explicit API for future use, but keeping some backwards-compatibility conveniences in the content-server for older clients? (Which may be what you're planning already).

Something like:

• If you're opted out of class-B encryption, you don't have a wrapKb value on the server.
• There's some new key-fetching API that returns the keys with explicit indications of which to use for what, and we update content-server to use them.
• 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.

Dunno. We could also reconsider "compatible with existing stable Firefox" as an explicit goal.

from fxa.

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.

Hacking 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.

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.

This 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.

I'm getting a bad feeling about the short-term-convenience vs long-term-complexity tradeoffs of this approach

I'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.

from fxa.

I see the complexity as being exclusively in the short term and getting phased out with new APIs

Is designing these new APIs part of the scope of this bug, or future work? If the former, then I think we're on pretty much the same page. If the later, I worry that we'd never get around to it and be stuck with just the hacky version for quite some time.

from fxa.

Is designing these new APIs part of the scope of this bug, or future work?

I think its prudent to design them now so Fennec can use them ASAP, but I don't have anything to propose yet.

from fxa.

👍

from fxa.

We've got 3 components we need to combine, app, key, and algorithm for the crypto to work. Currently this is all in code. Simple but not flexible. We want less in code in order to be more flexible, but only as much as we need. I think key and algorithm should be 1-1, which simplifies the model. There's no reason to allow a wrapKb key to be used in a kA algorithm, for example. (except in the above transition hack of course)

We want to be able to map the app to a key+algorithm. For example sync: 'kA' or sync: 'wrapKb' says, "for sync, use the 'wrapKb' key and algorithm as my sync key." or something...

I think the app -> alg mapping should be sessionToken accessible. It should be included in the signup/login result and have its own endpoint. I don't know what the name of the property should be so foo for now... I'm using "app" is this post, but in the broader context sounds too vague maybe.

/account/login & /account/create

{
  "uid": "4c352927cd4f4a4aa03d7d1893d950b8",
  "sessionToken": "27cd4f4a4aa03d7d186a2ec81cbf19d5c8a604713362df9ee15c4f4a4aa03d7d",
  "keyFetchToken": "7d1893d950b8cd69856a2ec81cbfd7d1893d950b3362df9e56a2ec81cbf19d5c",
  "verified": true,
  "authAt": 1392144866,
  "foo": {
    "sync": "wrapKb"
  }
}

GET /account/foo 🔒 sessionToken

{
  "sync": "wrapKb"
}

POST /account/foo

Setting the alg for an app is more involved. It probably needs to be authed with the password (or token?), ala /password/change/start

{
  "email": "[email protected]",
  "authPW": "7d1893d950b8cd69856a2ec81cbfd7d1893d950b3362df9e56a2ec81cbf19d5c",
  "sync": "kA"
}

I think that the minimal API we'll need to support this. I'm still thinking through the flows...

from fxa.

Maybe we can defer the "setting" endpoint for a while... The security of that is important and deserves special care, especially in a downgrade operation.

from fxa.

Some of our incoming user stories also suggest more general "service configuration" management could be in our future, e.g. #37 and #31. Worth thinking about how that might intersect with the API here.

from fxa.

I think key and algorithm should be 1-1, which simplifies the model

Strong +1 to this

from fxa.

Also, realized I should have linked this when I was talking about Hello above: https://github.com/mozilla/fxa-content-server/blob/master/docs/relier-keys.md

from fxa.

cc @ncalexan @ckarlof

from fxa.

At the moment I'm implementing the kA hack by having the auth-server return an override_unwrapBKey field on login (when kA is the pref) that the content-server will send to "old" browsers as unwrapBKey. This eliminates the "tricky" part above.

from fxa.

Should we close this or keep this around @dannycoates @rfk ?

from fxa.

I'm sure this topic will come around again before too long, but let's close it out for now; we can get back to it later if/when needed.

from fxa.