[proposal] X-Client-State header for Sync relaunch

Nick Alexander 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:

**X-Client-State**
     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.

Initial put

How about HKDF(kB, salt=emailUTF8, context=KW("X-Client-State"), 16)?

Thoughts

* 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.

Thoughts?

Nick


More information about the Sync-dev mailing list