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

@jyasskin commented on this pull request.

I'm still not confident enough that this is an improvement over the [original proposal](https://github.com/w3c/webappsec-dbsc/blob/main/README.md) to think we should insist on it, but I also don't want to block progress if other folks on the TAG think it is. And I do think that the proponents should explore the idea of signed cookies with liveness proven by a path component.

> +This is based on the idea that stealing a key pair —
+especially one that can be saved in a trusted platform module (TPM) —
+is much harder to steal than cookies.

Nit:

```suggestion
This is based on the idea that stealing a key pair —
especially one that can be saved in a trusted platform module (TPM) —
is much harder than stealing cookies.
```

or

```suggestion
This is based on the idea that a key pair —
especially one that can be saved in a trusted platform module (TPM) —
is much harder to steal than cookies.
```

> +
+Note that the server does not need to refresh the signed cookie.
+That cookie could be a stub that only exists to elicit a signature, so it could have a very long lifetime.
+
+
+#### Reducing Latency
+
+The need to manage liveness,
+centralize the management of login refreshing,
+and provide the server with control over when signatures occur
+each potentially add latency.
+
+In the original proposal, reliance on the client clock potentially removed one round trip,
+that being the first in the example above.
+
+The first and most obvious way to reduce latency is to have all resources be able to redirect

```suggestion
The first way to reduce latency is to have all resources be able to redirect
```

"obvious" always risks being insulting, and it's unnecessary words anyway.

> +and provide the server with control over when signatures occur
+each potentially add latency.
+
+In the original proposal, reliance on the client clock potentially removed one round trip,
+that being the first in the example above.
+
+The first and most obvious way to reduce latency is to have all resources be able to redirect
+to the high entropy resource that requires a signature.
+That is, the server redirects directly from `/some/resource` to `/login/sign/...`.
+That optimization “only” requires coordination in the server,
+to ensure that redirects are not triggered by multiple fetches.
+
+The scoping arrangement in the JSON session description potentially gave servers
+the option to make a cookie that triggered a signature refresh on some requests and not others,
+though this is inflexible due to overlap between the scoping in that session description and in cookies.
+That is, the session description could ask for refreshes on `/foo/bar` for cookies with a path of `/foo`.

I had to read this a couple times to understand it. Perhaps:

```suggestion
That is, the session description could ask that cookies with a
[`Path`](https://datatracker.ietf.org/doc/html/rfc6265#section-5.2.4) of `/foo`
be refreshed using a request to `/foo/bar`.
```

> +to ensure that redirects are not triggered by multiple fetches.
+
+The scoping arrangement in the JSON session description potentially gave servers
+the option to make a cookie that triggered a signature refresh on some requests and not others,
+though this is inflexible due to overlap between the scoping in that session description and in cookies.
+That is, the session description could ask for refreshes on `/foo/bar` for cookies with a path of `/foo`.
+
+That arrangement can be used to hide latency.
+Consider that a site could serve up HTML for `/foo/page.html`,
+which might be able to recognize that the cookie is due for a refresh.
+The response could forcibly expire the cookie
+and force a fetch for a resource at `/foo/bar` in the background.
+That fetch would cause the session refresh to occur,
+without necessarily delaying the page load.
+
+A similar approach is possibly under the alternative design.

```suggestion
A similar approach is possible under the alternative design.
```

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

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