On 9/01/2014 10:36 AM, Brian Warner wrote:
>
> 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 had a good chat about this today, and have agreed to reconvene early
next week and make a final call on these details. I want summarize the
discussion so far, and highlight two broader points for folks to chew on
over the weekend.
> * the fxa-auth-server will remember a "generation number" for each
> account. Each account-reset and change-password event increments the
> generation number. The generation will be included in signed
> certificates returned by the /certificate/sign API.
>
> * the Sync tokenserver will maintain a table with three columns:
> - FxA Account Identifier
> - FxA generation number
> - Sync account identifier (endpoint? collection-id? I don't know the
> right lingo)
>
> * If the tokenserver gets a please-give-me-a-token request with a
> generation number that's lower than the one currently stored, it
> should reject the request. If it gets a cert with a higher generation
> number, it should update the table.
r+
Everyone seems happy with this change, let's make it so.
We should try to push this into upstream BrowserID standards as an
optional extra feature.
> * when the client submits a signed assertion to the tokenserver's
> "please give me a token" API, it will include the hash of the
> encryption key it is currently using (derived from kB). nalexander:
> I'd recommend this value be a sibling of the key you're already
> deriving from kB, either by using a different ctxInfo string, or by
> extracting an extra 32 bytes from the existing HKDF operation. Neither
> is derivable from the other.
>
> * The Sync account identifier must be a consistent function of (FxA
> account-id, hash-of-encryption-key). Previously it was merely a
> consistent function of the FxA account-id.
>
> * the FxA/Sync client code should respond to most errors (specifically
> token-expired and old-generation errors) by asking the user to
> re-login
Chris accurately summed up my concerns here as follows: this will work
as advertised, but smells funny.
Let's be explicit that there are two categories of things we are
deploying for the FF29 deadline:
1) Shiny New Things that we plan to improve and re-use in the future.
2) Janky Old Things that we plan to replace at first opportunity.
The FxA server is clearly in (1) and the SyncStorage servers are clearly
in (2). Only category (2) is allowed to smell funny, and boy, does it ever.
So which of these is the TokenServer?
ISTM that this proposal assumes it is a Janky Old Thing, and Toby and my
initial resistance is because we consider it a Shiny New Thing.
> * resetting your account (new password, new encryption key) should *not*
> result in clients seeing HMAC errors, when they try to decrypt new
> records with the old key or vice-versa
Are we falling into the "let's fix sync while we're at it" trap here?
HMAC errors are a fact of life in the current sync system, and are just
one of its many wonderful failure modes. What makes this failure mode
special enough to deserve a fix in the FF29 timeframe?
That's not a rhetorical question; I can imagine at least two possible
answers:
* they would occur much more frequently with the new auth
* the fix is free with a neat hack in the Janky Old TokenServer
Cheers,
Ryan
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
