Re: [w3ctag/design-reviews] Device-Bound Session Credentials Analysis (PR #1094)

@martinthomson commented on this pull request.



> +
+This does not use WebAuthn for storing keys, but rather depends on an unspecified key storage location.
+This is primarily due to some inherent inflexibility in WebAuthn
+around how tokens require user interaction for enrollment and (sometimes) usage.
+The goal is to make keys available for use transparently,
+so that sites can activate the feature without any additional user interaction.
+
+Part of the reason for this feature is to allow sites to extend login times,
+so that people that visit sites need to reauthenticate less often.
+Short cookie lifetimes are often driven by a desire to manage the risk of cookie theft.
+The need to refresh logins on sites is not the only reason that sites time sessions out,
+but it is a major factor driving the need to enter passwords.
+This would not guarantee that sites would ask for passwords less often, but it would be good if it had that effect.
+
+There are two major parts to the design of this feature: enrollment and usage.
+This document will first look at usage, because that is the part that could be simplest.

I deliberately put usage first, because that is the important one and it is the easiest to reason about.

> +Overall, this creates a new set of interaction paradigms between the browser and websites.
+We think that there are easier ways to achieve the same basic goals
+without too much disruption to the existing cookie handling arrangements.
+That design is sketched below.

I think that you are underestimating the complexity of a model in which you have to stand up a special service just to manage these cookies.  Obviously, a large part of that complexity burden is borne by the browser implementers, but trying to extract the right behavior from that model is likely to lead to equivalent complexity, if not more, than the alternative.  Don't be mislead by the completeness of the example: all that complexity is present in the original proposal, plus more.

> +That design might include a new `Signed` parameter for cookies in `Set-Cookie`.
+That attribute would request that, whenever the cookie is sent to the server,
+the client would cover that cookie with a signature.

To be clear, I didn't look too closely at the federation text there.  The potential that things might be linked without going through the accepted processes (FedCM primarily, though also Storage Access on its own) concerned me enough to discount this.

Again, this is a case where the signing of the cookie allows for self-service.  Under any regime where you can obtain unpartitioned cookie access, this is pretty trivial.  The embedded SP (or IdP) gets the signatures it would have normally.  It can then tell the top-level site that everything is good.  At which point the top-level site can either set an ordinary cookie or it can do its own binding to a key in the TPM, remembering how it was blessed.

BTW, that whole idea about guessing secrets is a fine one, but orthogonal to this.  This is about ensuring that cookies cannot be stolen.  It is also probably an idea that makes cookie theft even more consequential, as it creates a way to stealthily track if you can guess correctly.

> +It is not likely to be sufficient to just cover `Cookie` in the list of signed content in `Signature-Input`.
+Including a date (the `created` parameter), the method (`@method`), and the URL (`@target-uri`)
+seem to be the minimum set of things that will prevent the signature from being reused.

That doesn't argue either way for something like that.  Either something needs to be signed to achieve some goal, or not.  How something is spelled has no effect on that.

The only reasons I can see that would justify a distinct header are:

* to ensure that you don't get a signed cookie back from a client that doesn't understand the new feature
* to avoid all that `__Secure-`/Secure, HttpOnly, etc baggage that cookies have accrued over time

The first is pretty trivial to handle gracefully.  The second has a long history of failure.

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

Message ID: <w3ctag/design-reviews/pull/1094/review/2867012842@github.com>