Re: [w3ctag/design-reviews] Early Design Review for Device Bound Session Credentials (Issue #1052)

arnar left a comment (w3ctag/design-reviews#1052)

Thank you Martin for thoughtful feedback.

> The question is then only whether to delay (at the browser end, by serializing requests) or make requests without signatures (which will need to be retried somehow).

This is spot on and the most important point. The complexity, which you are right to point out, comes almost entirely from choosing the former approach. The reason we (Google) are proposing the former, is because we tried the latter in a few different versions, and found that every time we underestimated the server side complexity, and the difficulty of migration. 

If the server has to trigger the condition "now I require a signature" at the moment it is needed, it turns out that it only works well for requiring signatures on certain sensitive actions, or explicit re-auth moments that are visible to the user. That (a) significantly limits how often we can observe binding signatures, and (b) requires application-level changes across the whole stack, which are infeasible. We don't think that's a Google specific problem, it's akin to requiring framework upgrades or migrations for other regular ("second order" in your first link) apps.

We tried implementing a "collect a signature every 10 minutes" type of logic in that framework. The fact that the browser will make requests without a recent proof means that any application on the domain has to be prepared to handle it, trigger a signature collection, and then retry the original request. The request that triggers it can be any type of request, a full page redirect, a load of an <img> src attribute, or, most frequently, an XHR. Creating semantics for reasonable "retry" here seems infeasible, and even if it is, it will be bespoke to each application and/or framework in use.

So from our point of view, browser-initiated refreshes and holding requests until a refresh is done, is something we think is necessary for success here.

>> We do not believe this scales well.

> I suggest that you are criticizing an aspect of the complexity that is emergent, not inherent. 

I do think this is inherent. You identified one of the large issues with server-side triggered signature requirement, which is that multiple concurrent requests may prompt the server to issue multiple signature requests (e.g. redirects to endpoints with a Signed cookie, or specific XHRs, etc.). I believe that any solution this requires servers to keep consistent state across all its instances, which is very hard to scale.

In your solution in particular, which iiuc was to have those requests first go through an endpoint without a Signed cookie, that then coordinates and redirects /one/ of them to the "real" endpoint (one that has the Signed cookie), while somehow keeping the others pending, or redirecting/404ing them right away to whatever is appropriate. Such a redirect endpoint will need fully consistent state to make such decisions. Apologies in advance if I misunderstood your suggestion.

> My first goal is to remove the reliance on the browser clock to drive refreshes. 

In our proposal sites do manage when signatures are needed by telling the browser up front, via the expiration time of the short term cookie. In practice, we expect this to be measured in minutes or hours, and that sites will set this with the Max-Age attribute.  We have not seen widespread issues with clients keeping fairly good relative time on that scale. Clock drifts/changes can indeed happen, but they are rare, and when they do the remedy seems simple enough: If the browser sends a stale short-term cookie, the browser force expires it which triggers a refresh; and if the browser expires one too early then a refresh will be triggered and the server sets a new cookie.

> That leaves proactive refreshes. I don't see that as viable, frankly.

We believe simple logic will be fairly effective here. Since the website has told the browser in advance when it will need signatures, via the expiration of short-term cookies, the browser has a lot of information. An example of simple logic here would be "If requests requiring the short term cookies have been made in the last minute of its lifetime, perform a refresh 10 seconds before it expires" (with tunable parameters).


-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3ctag/design-reviews/issues/1052#issuecomment-2975084078
You are receiving this because you are subscribed to this thread.

Message ID: <w3ctag/design-reviews/issues/1052/2975084078@github.com>