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? (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
