On 11/01/2014 2:58 PM, Richard Newman wrote:
>>> * 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?
>>
>
> At the risk of weighing in here when I've been on PTO and haven't thoroughly
> read the whole thread:
>
> HMAC errors *should not* routinely occur in current Sync. We went through a
> patch where they did -- because the client processed a node reassignment
> request by just pointing its firehose at the new server, writing records but
> no meta/global or keys.
>
> They will occur in a few specific scenarios:
>
> * When you change your Sync key. Your other clients will fail to decrypt
> crypto/keys, and prompt you for your new Recovery Key.
>
> What we're aiming for here is that making some kind of routine change to your
> account (e.g., password reset) does not open you up to a window in which
> another client can write data using a different chain of keys, *and have it
> stick around*.
Isn't "change your sync key" in the old system roughly isomorphic to
"reset your password" in the new system? If we have an existing flow
for handling the former, I don't understand why it wouldn't work just as
well for the latter.
Of course, "work just as well" is not the same thing as "work well"...
> The risk is that any client with a token can write -- potentially during the
> post-reset wipe. What it writes will be encrypted with the wrong kB.
Does this same race exist in the current system, if you change your sync
key on one device while another is in the process of syncing?
> The 100% safe way of doing that is for a password reset to involve a node
> reassignment. The resetting client gets the new assignment immediately, and
> can write its new stuff before anyone else gets to. The other clients get the
> new assignment *when their token expires*.
Yeah, I agree that new password => new bucket is the most reliable way
to avoid these problems.
Cheers,
Ryan
_______________________________________________
Sync-dev mailing list
Sync-dev@mozilla.org
https://mail.mozilla.org/listinfo/sync-dev
