Alternative short-lived refresh design

[martinthomson]

@arnar and I talked about the general problem statement at TPAC, but never really concluded that discussion to either of our satisfaction.

As noted in the TAG review, the primary concern is the unitary nature of the design. The TAG likes the overall problem statement and is supportive of the general approach, but would prefer to see a modular design. There are elements in this document that cover most of that, but the question of how the short-lived cookie is refreshed remains a sticking point.

I think that the problem statement basically equates to this:

1. Refreshing the short-lived cookie that is issued in response to receiving a signature from the TPM becomes far more important in this new model. The goal is to ensure that refreshes are frequent, so you have continual assurance of the liveness of the signing key, but not so frequent that the TPM is overloaded.
2. Sites that rely on periodic refreshes, such as fetching new email or getting document updates, are most exposed to the short-lived cookie expiring.
3. Those sites are generally poorly set up to manage expiration. They have processes for dealing with a need to reauthenticate, but those are typically much more disruptive because they are built for longer-lived cookies expiring. Typically, that means triggering a user-level authentication flow, including passkeys, 2FA, and the works. You don't want to risk firing that every few minutes.

Overall, there is a strong desire to have the browser recognize that the cookie is expired and have it automatically refreshed before any request that might need to fail.

The present design is all based on the JSON controller document that acts as something of a controller for multiple cookies and resources. There is also a formal notion of a session, which encompasses the use of keys, scopes, refresh sources, and more. For refreshing cookies, that design has the site publish the set of places that cookies need to be provided, plus how those cookies are refreshed. That's quite a bit of complexity to manage.

Continuing from the more modular alternative design proposed, just looking at the refresh component, here's a potential approach¹.

Set-Cookie: shortlived=123; Secure; HttpOnly; Max-Age=600; Path=/OtherPath;
  Refresh=/RefreshEndpoint; Refresh-Time=86400

This says that the cookie is good for 10 minutes, but the server asks that the browser attempt to automatically refresh the cookie for up to a day before using it if it expires.

The way the cookie is refreshed is to fetch the identified URL. The browser would be told to make that request before proceeding with a fetch, without a cache (cache-mode = "no-store" or maybe "reload"), just like in the present design. The difference being that you don't have a need for the notion of a session to drive this design.

The only tiny catch is that this is not valid if Path is unspecified or a prefix of Refresh. Otherwise, you create a circular dependency.

The Refresh-Time thing might be optional if we can agree on a default, or even a fixed value. It seems like this could be almost arbitrarily long, up to however long the browser is willing to hold a cookie for.

This doesn't look significantly different, except that the cookie itself encodes its own refresh criteria. There are other things you might consider adding (I'm unconvinced of the utility of caching a challenge or including a session ID, for instance; both are something the site could put in the URL instead, not requiring the browser to do anything special).

As indicated in the linked analysis, whether this refresh endpoint² is the one that asks for a signed cookies is up to the server, but I would generally recommend that the server use a redirect on that fetch so that it can provide a fresh random challenge and demonstrate true live access to the secret key.

Overall, this could be more modular than what is presently proposed. It offers a new tool for servers that want to manage cookie issuance centrally, for more than just this one case. I won't pretend like this addresses all of the details that have been integrated into the present design (what if the TPM is overloaded? how does this interact with navigation?) but hopefully it shows an alternative path for the requirements, as stated.

Footnotes

1. With thanks to GitHub's "http" syntax highlighter, which has helpfully highlighted the parts I'm proposing to add. ↩

2. As an HTTP person, we don't refer to these things as endpoints. The term we prefer is "resource". ↩

[benweissmann]

I just wanted to chime in with some thoughts from my experience writing a server-side DBSC implementation.

I'm not sure I follow how the DBSC registration flow could be completely replaced with new Signed and Refresh attributes on Set-Cookie (in particular, I'm not clear on how this design would support a) graceful fallback for older browsers, b) federated sessions with an IdP, and c) mitigations against timing side-channels). However, I did find the JSON Session Instructions to be the most complicated part of implementing DBSC server-side. In particular:

• I'm not clear on the utility of session_identifier, and what use it has that couldn't be covered by either a) setting an additional session ID cookie, or b) including a session identifier in the registration and refresh URL (as @martinthomson noted above). In my implementation, I just used a hard-coded, static value since I had no need for this field.
• I also found it confusing how scope and credentials.attributes in the Session Instructions related to the attributes of the Set-Cookie headers that the server returns from the session endpoint. If we do keep the session registration flow, I wonder if both scope and credentials could be combined into just a list of cookie names, with the requirement that matching Set-Cookie headers must be present in the response, and then the current "scope" and "attributes" from the session registration would just be read from those existing Set-Cookie headers. I worry in the current design that the overlapping responsibilities of the paths and domains in the Set-Cookie headers, and the scope and credentials.attributes fields in the Session Instructions makes implementation difficult and error-prone.

[martinthomson]

Let me see if I can help with the three cases you were unclear on:

a) graceful fallback for older browsers

When you ask for a signature on a cookie using Signed, you would not get a signature from an old browser. That cookie would be sent on a request that would populate a short-lived cookie. In response, the old browser can get one sort of cookie and the new browser gets a different one. The browser that signed the cookie will do the new things, so you can set a pretty aggressive timeout and ask for refresh (and re-signing) as often as you need (10 minutes or whatever). The old browser will do whatever you do today with login cookies, which probably means lasting a bit longer, but triggering more disruptive UX when that happens.

Note that you might not get one from a new browser too, if the TPM is overloaded at the time, so you need to handle this case always. It's probably a good idea for browsers to have a baseline rate of failure to stop sites from getting complacent about fallback.

b) federated sessions with an IdP

I'll admit to not having thought a lot about this, but the basic arrangement described in the draft would seem to transfer pretty well here. It means that the RP needs to ask for access to the SP key, proving no information gain (or privacy leak) by making that key known. That would require a different set of attributes (but no need for session ID) somewhere. (It might be possible to put those on Accept-Signature.

c) mitigations against timing side-channels

I have to confess to negatively caring about this aspect of the design. Third-party cookies are a misfeature and I have no interest in solving for it. Recall that when third-party cookies are enabled on a site, the user loses privacy. I get that the concern is about something else: cross-site security, where information from the third-party leaks to other sites participating in the same context. The solution is to not make this feature available in third-party contexts, not to add an allowlist.

[martinthomson]

Just noting https://datatracker.ietf.org/doc/html/draft-hardt-httpbis-signature-key-00 as a development in this area.