On Feb 20, 2014, at 7:13 PM, Ryan Kelly <[email protected]> wrote:
> On 20/02/2014 8:23 AM, Chris Karlof wrote: >> Here are my recommendations: >> >> 1) *Don't remove Hawk where we're currently using it*. It will be too >> disruptive at this point in time. >> >> 2) *Dramatically scale back the replay protection of Hawk. *Hawk allows >> a time window of 1 min by default. I propose we change that to something >> big. A day, a week, a month, a year. Turn the knob until we stop seeing >> problems. This is a server side change, so we can keep cranking until >> the problem diminishes to a level we're comfortable with. We could turn >> it off completely (i.e., time window of infinity), but I think there is >> some value to keeping *some* replay protection beyond what is already >> provided by TLS. Even if we turn off the replay protection of Hawk, we >> still get other benefits from it (e.g., not leaking the actual token in >> every request). >> >> 3) *Keep the servers in time sync. * > > There's also a non-hawk-related timestamp issue that has popped up from > time to time - the client-provided expiry time in the BrowserID > certificate. Has this been much of a problem in practice, and is there > anything we can do there apart from adjust-for-skew-and-retry? > As we discussed in yesterday's standup, we need to make sure that the "iat" and "exp" times in the browserID assertions are being properly skewed adjusted (at least in the near term if we aren't turning on the checking of these in the verifier). The is still feasible because the auth server returns a server timestamp for each request in the timestamp header: https://github.com/mozilla/fxa-auth-server/blob/master/docs/api.md#response-format However, I'm concerned because the Desktop code in hawk.js doesn't use this. It instead uses the Date header to adjust skew: http://mxr.mozilla.org/mozilla-central/source/services/common/hawk.js#157 This is differs from the fxa-js-client, which doesn't do continuous adjustment. It only does it in response to timestamp errors, and when it does recover, it uses the timestamp in the server response, not in the header: https://github.com/mozilla/fxa-js-client/blob/ba19a332489afc2f98da2e9b92c147e47942838d/client/lib/request.js#L69 I'm also suspicious about the removal of this line, which removes using the Date header to adjust for skew: https://github.com/mozilla/fxa-js-client/pull/67#discussion_r9342366 So some questions: 1) Is it ok (in at least the near term) for Desktop to use the Date header to adjust for skew instead of our Timestamp? 2) What does Android do? 3) Is it ok (in at least the near term) for the JS client to only correct in response to errors, and use the value in the error response to do so? Longer term, I don't like that the JS client and Desktop code are doing it differently, which is probably also different from how Android does it. -chris > (At least this case is localized to just the tokenserver client code, > and doesn't need to be reimplemented all over the place) > > > Ryan
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
