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

@jyasskin commented on this pull request.



> +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.
+
+# The Proposed Design

It's not clear in this discussion when we're describing what they've proposed vs describing our alternative proposal. So, let's coin a name (other than "current") for the incoming proposal. Here I'm using "the webappsec-dbsc proposal", but we could pick any distinctive name. Then we can call ours "the TAG proposal".

```suggestion
# Restatement of the webappsec-dbsc proposal
```

It would also be good to globally increment the heading level: the top of the document has an `<h1>`, so the top-level section headings should really be `<h2>` or `##`.

> +
+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'm getting confused by seeing usage come before enrollment, since chronologically enrollment happens first and establishes that conditions that make usage possible. Can you swap them?

> +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.

Use of the DBSC proposal seems fairly simple, while the alternative looks more complex to me, even if it might trust client-side clocks too much. We should acknowledge that here.

I think the key benefit of our alternative is that it adds a simpler primitive to the platform, and even though use is more complex, that single new primitive can combine in very interesting ways with the rest of the platform.

> +## Complexity
+
+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.
+
+# An Alternative Design
+
+This is a sketch of an alternative approach that is closer to how the web platform currently handles cookies.
+
+The core requirement for the usage part is that the site is able to
+regularly request that the browser demonstrate that it has access to the private key
+that was registered through the enrollment process.
+Ideally, that access is not required for most interactions,
+because generating and validating a digital signature is somewhat expensive for both client and server.

```suggestion
because generating and validating a digital signature is somewhat expensive for both client and server,
especially, for the client, if the key is stored in a TPM.
```

> +
+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.
+
+The use of the `Path` cookie parameter would ensure that
+`Signed` cookies are only sent when requests are made to specific resources.
+That would allow servers to limit how often they ask clients to generate signatures
+by limiting how often the client requests the identified resources.
+Those requests could be initiated through a redirect, fetch, or any other request, as needed.
+
+The choice of what fields to include under the signature is very important.
+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.
+It's possible that a more thorough security analysis will identifier other fields that need to be covered.

```suggestion
It's possible that a more thorough security analysis will identify other fields that need to be covered.
```

> +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.

It looks to me like signed cookies need enough extra handling that they might deserve a new `Set-Signed-Cookie` header instead of just a `Signed` parameter. In particular, for creation, it's important that the client immediately make a request with the new public key, so the header ought to identify a URL that should be the target of that request.

Then ... in what ways is `Set-Signed-Cookie` different from `Secure-Session-Registration`? One way is that it doesn't intrinsically have support for https://w3c.github.io/webappsec-dbsc/#federated-sessions. We haven't analyzed the federated sessions in this document. They're a bit like a proposal Johann made to grant storage access if one site could prove that it knows a secret that's only available to another site...

> +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.

Here's another use for a dedicated `Set-Signed-Cookie` header: it could list the component identifiers that need to be signed.

> +if that resource is less critical to protect.
+This is more flexible because it is not tied to specific path prefixes.
+It could instead be for other reasons,
+such as whether the request is for protected information or actions.
+Resources can then trigger asynchronous fetches to refresh cookies,
+ahead of when any critical resources need to be fetched.
+
+
+## Communicating Keys
+
+Enrollment can almost be a side effect of creating and first use of a `Signed` cookie.
+The only requirement here is that the browser learns what types of keys are acceptable to the server
+and that the server learns the public key that the client uses.
+
+Any `Set-Cookie` header that establishes a `Signed` cookie could list the key types in the `Signed` attribute,
+but the `Accept-Signature` field exists for negotiating the use of signature keys.

```suggestion
but the [`Accept-Signature` field exists for negotiating the use of signature keys](https://www.rfc-editor.org/rfc/rfc9421.html#name-requesting-signatures).
```

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

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