Hi all, but especially warner and ckarlof,
From [1]:
"""
There is no MAC on wrap(kB). If the keyserver chooses to deliver a bogus
wrap(kB) or kA, the client will discover the problem a moment later when
it talks to a storage server and attempts to retrieve data from an
unrecognized collection-ID (since we intend to derive collection-IDs
from the key used to encrypt their data, which will be derived from kA
or kB as appropriate). It might be useful to add a checksum to kA and
wrap(kB) to detect accidental corruption (e.g. store and deliver
kA+SHA256(kA)), but this doesn't protect against intentional changes. We
omit this checksum for now, assuming that disks will be reliable enough
to let us never experience such failures.
"""
Our current plan is to bucket user's sync storage by the tuple of
(email, key-fingerprint, and certificate generation) [2]. It's worth
calling out that clients that don't compute keys correctly, or are
intentionally misled about their keys, will appear to the sync protocol
as being the only client in the cluster (since clients learn about their
peers via the clients collection).
I don't think we need to take any action other than to update the onepw
docs.
Nick
[1] https://github.com/mozilla/fxa-auth-server/wiki/onepw-protocol
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=959441
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
