On Feb 20, 2014, at 7:46 PM, Chris Karlof <[email protected]> wrote:
> > 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. > > Legacy assertions don't have an "iat" field, but the new format does: http://lloyd.io/evolving-browserid-data-formats/ The verification of assertions is done by jwcrypto in the verifier, which doesn't have a straightforward way of letting us indicate that we should ignore the checking of the "exp" time in the assertion part: https://github.com/mozilla/jwcrypto/blob/master/lib/assertion.js#L83 So these means that if time skew in the client generated "exp" is a problem in practice (even after all the time skew adjustment crap we have in place), I think the best option on the table is to just make "exp" in the assertion part to be "significantly" in the future. -chris >> (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
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
