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

@jyasskin commented on this pull request.

Initial thoughts, but I won't get through the whole change before the meeting.

> +That new field could be replaced either with a per-account resourc.
+URL parameter or a non-DBSC cookie.

Typo here. Maybe:

```suggestion
That new field could be replaced either with a per-account resource-URL
parameter or a non-DBSC cookie.
```

> +thereby proving to the server that the browser still has access to the key pair.
+The response to the second request refreshes any of the affected cookies.
+
+This adds two round trips of latency every time that a cookie refresh is needed.
+While some amount of delay is likely unavoidable, having two additional requests is fairly heavyweight.
+
+We have an alternative below that doesn't require an interactive exchange.
+However, given that TPMs generally don't have a clock,
+you can't use the clock to ensure freshness.
+A non-interactive exchange might have been pre-generated by an attacker
+who temporarily had access to the TPM, unless it contains fresh entropy from the server.
+That's something we address in more detail in the alternative design below,
+noting that the alternative offers servers more options to combine requests to reduce latency,
+where the proposal cannot.
+
+The proposal includes a redundant new session identifier field in requests.

Is it redundant if it would have to be replaced with something?

> +We have an alternative below that doesn't require an interactive exchange.
+However, given that TPMs generally don't have a clock,
+you can't use the clock to ensure freshness.
+A non-interactive exchange might have been pre-generated by an attacker
+who temporarily had access to the TPM, unless it contains fresh entropy from the server.
+That's something we address in more detail in the alternative design below,
+noting that the alternative offers servers more options to combine requests to reduce latency,
+where the proposal cannot.

Is it worth spending time on this? It'd be possible to tweak the proposal to avoid the interactive exchange too, with just a flag in the enrollment that causes it to use a constant challenge.

> +In the proposed design,
+the browser understands that when it makes a request to one of the resources that participates in the protocol,
+it is expected to hold refreshed versions of the identified cookies.
+
+These cookies are expected to have very short validity periods.
+The browser is able to refresh those cookies automatically by interacting with the session resource.
+The main part of the protocol is the interactions between the browser and that session resource.
+
+Interactions with the session resource are a two-step process.
+The first is a simple request that retrieves a fresh challenge.
+The second posts a signature from the secret key over that challenge,
+thereby proving to the server that the browser still has access to the key pair.
+The response to the second request refreshes any of the affected cookies.
+
+This adds two round trips of latency every time that a cookie refresh is needed.
+While some amount of delay is likely unavoidable, having two additional requests is fairly heavyweight.

We shouldn't say 2 round trips are heavyweight unless we have an alternative that we think is just as good, that only requires 1 round trip.

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

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