On Feb 20, 2014, at 7:13 PM, Ryan Kelly 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.
I think I was trying to will this problem out of existence. > Has this been much of a problem in practice, and is there > anything we can do there apart from adjust-for-skew-and-retry? > "iat": 0 "exp: 99999999999999999999 for the assertion payload part. The validity of the chain will be limited by the lifetime of the signed public key anyway. We will magically solve server sync with NTP and the -10s hack will the address razor edge situation. > (At least this case is localized to just the tokenserver client code, > and doesn't need to be reimplemented all over the place) > Yay, client side. We could also just turn off checking of iat and exp in the assertion payload part in the verifier as well. It's worth noting that if we disable timestamp checking on FxA, and there is skew, then the token server requests will fail (with no recovery) because it currently relies on the skew adjustment value from the FxA server (returned in error) to adjust the exp time for the assertion payload. We could also just make the TS an Oauth2 relier. Ha! j/k. sort of. -chris > > Ryan _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
