> 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"…
:D I'm not saying that the new system is definitively better or worse than the current one; just explaining the narrow set of situations in which HMAC errors can occur. In existing Sync, password changes take effect immediately, and sync key changes are independent of passwords and are always effected by clients (versus reset password on the web?). Those constraints no longer hold for Sync+FxA, so we can't assume that the system will have the same failure states. >> 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? Yes. More broadly, there's always the possibility of a race between a wipe and a blind sequence of writes. There's no way around that without having some kind of cross-resource consistency checking (effectively XIUS on meta/global and crypto/keys for all writes). That said, a client that uploads a record encrypted with the wrong key will see a new crypto/keys on next sync, and should reupload records as necessary (unless that's regressed since it was built). That should cause a convergence on correct records. But again, all code implicitly includes the assumptions that applied when it was built, and those have changed, so we're in new territory here unless we can prove otherwise. >> 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. Can we do that in time for release? (And get a QA plan to match?) _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
