[proposal] X-Client-State header for Sync relaunch
nalexander at mozilla.com
Mon Jan 27 09:46:22 PST 2014
Sync relaunch clients need to provide the X-Client-State header to the
token server in order to not hit HMAC errors on key changes. We need to
do this, it needs to be secure, but we can't version it client-side. Whee!
From the token server docs:
An optional base64-urlsafe string, up to 32 characters long, that
can be sent to identity a unique configuration of client-side state.
A change in the value of this header will cause the user's node
allocation to be reset. Clients should include any client-side state
that is necessary for accessing the selected app.
How about HKDF(kB, salt=emailUTF8, context=KW("X-Client-State"), 16)?
* SHA256 is 256 bits, i.e. 256 / 8 = 32 bytes long. I interpret the
server's "32 characters long" to mean the resulting string, so we have
16 bytes to work with, and therefore SHA256 is not trivially usable. (I
don't know an obviously secure way to take a 32 bit hash and generate a
16 bit hash from it.) We could bump the server to allow for 32 bytes.
* We want to salt whatever we're doing at least per email address, since
we don't want a straight dictionary attack on the space of all addresses.
* We don't want to give an oracle to testing kB, but we pretty much have
to in order for clients to get the comparison they need. We're not
going to do a zero-knowledge proof here.
* It's irritating to include emailUTF8, since this is Yet Another Place
for email case normalization to bite us.
More information about the Sync-dev