Accept-Signature request header

[wrygiel]

Related to https://github.com/w3c-dvcg/http-signatures/issues/13.

The client knows when the server wants the client's signature, and what algorithms the server supports, because the server communicates this in its WWW-Authenticate header. Perhaps it would be a good idea to propose a similar standard way of communicating this in the opposite direction? So that the server knows when the client wants the server's signature?

In our system we are planning to use multiple server authentication schemes. We need a way for the client to communicate that it wants the server to issue a Signature. It would also be nice for the client to be able to include the preferred signature algorithms, for example, in similar fashion as in the RFC3230's Want-Digest header.

[msporny]

We're trying to keep the spec simple and doing what you want above would add even more to the spec. I'm not saying it's not useful, it sounds useful, but you're the only one that has raised this use case so far (in the over 5 years that the spec has been in development). There are many shortcomings to the spec, but we're trying to keep it very limited by design. That said, i'll try to play around with some extensions to the spec and see how many people implement those extensions. If we get 6 out of the 9 implementations supporting it, we can roll it into the main spec.

That said, my time is very limited today, so perhaps you'd like to write those extensions up as an IETF spec that extends HTTP Signatures?

[liamdennehy]

I'm leaning more and more towards this being a good idea. Given the apparent threat in having the algorithm being uncontrolled, and different headers the receiver can process (including implementations that for some obscure reason explicitly define the order), this would be a good mechanism to communicate those minimums - especially in the case of errors & rejections. This allows clients to implement signatures in a more autonomous way, especially as the verifier changes their requirements.

For example:

  Accept-Signature: headers="(request-target) date digest content-length -user-agent +",algorithm="!rsa-md5 -rsa-sha1 rsa-sha256 ec-sha256 +rsa-sha512 +ec-sha512"

would communicate:

• Four mandatory headers (as well as showing the order a verifier would expect or require them to be presented)
• One prohibited header
• The option to sign additional headers the client deems useful (indicated by + at the end, otherwise it is a non-extensible list)
• One prohibited algorithm, possibly in response to an attempt to use that algorithm in the previous request
• One deprecated algorithm that is acceptable but would not be acceptable in the future
• One acceptable algorithm
• Two further preferred algorithms

This would also be useful in an OPTIONS response, and could also be used by the client to indicate which parameters are acceptable in the response signature.

This could all be a MAY implement to preserve compatibility as it is explicitly a quality of life extension. This would, as pointed out, increase the complexity of the spec.

[liamdennehy]

I now see https://github.com/w3c-dvcg/http-signatures/blob/18a4cbdb350ac2f02826e5567995fefe52c095fb/index.xml#L445 has a mechanism to handle this already, though it is focused on the Authorization header (maybe).

[wrygiel]

Just to clear up: The spec already specifies a way for the server to communicate its signature requirements (via the WWW-Authenticate header). What I was proposing in this thread is the opposite - I wanted the client to communicate its requirements (so that the server can sign its response).

[wrygiel]

BTW, we have ended up specifying a simple Accept-Signature header for our internal purposes (you can see its specs here).

[msporny]

I'm a -1 on this feature in this spec, again, not because it is not useful (it is), but it should go in a separate spec.

Four mandatory headers (as well as showing the order a verifier would expect or require them to be presented)

This seems useful

One prohibited header

What is the use case for this? Why do I care if you sign something in addition to the things I asked for?

The option to sign additional headers the client deems useful (indicated by + at the end, otherwise it is a non-extensible list)

Again, what's the use case? Is the added complexity of a DSL worth it?

One prohibited algorithm, possibly in response to an attempt to use that algorithm in the previous request

This would require the server to start storing state between requests, which adds complexity. What's the use case? I expect there is a simpler way to address it.

One deprecated algorithm that is acceptable but would not be acceptable in the future One acceptable algorithm Two further preferred algorithms

Again, added complexity for what benefit?

At present, the feature feels not fully baked. I think it should be more fully baked before going in the spec. @wrygiel has shown how this feature can be added in higher level protocols without it being in the base spec.

I'm also still struggling w/ the threat model for a client telling a server what it would like signed (feels like a replay attack in the making).

[liamdennehy]

One prohibited algorithm, possibly in response to an attempt to use that algorithm in the previous request

This would require the server to start storing state between requests, which adds complexity. What's the use case? I expect there is a simpler way to address it.

This is simply emitted when a request is rejected, not across requests

[liamdennehy]

Again, added complexity for what benefit?

Agreed, just laying out the full set of requirements if this were to be fully realised: If anything, making the case for not including it now.

[liamdennehy]

One prohibited header

What is the use case for this? Why do I care if you sign something in addition to the things I asked for?

I may have reserved that header for internal use - e.g. my gateway encodes info for the back-end system using that header. Very common in enterprise environments.

[liamdennehy]

Four mandatory headers (as well as showing the order a verifier would expect or require them to be presented)

This seems useful

If we would like to add this basic feature, then align with the Digest header spec, which specifies a Wants-Digest header with permitted algorithms.

[liamdennehy]

One deprecated algorithm that is acceptable but would not be acceptable in the future One acceptable algorithm Two further preferred algorithms

Again, added complexity for what benefit?

Allow a signer to determine dynamically which parameters to use, rather than requiring manual configuration. Nice-to-have, but still useful IMHO.

[liamdennehy]

I'm also still struggling w/ the threat model for a client telling a server what it would like signed (feels like a replay attack in the making).

Server (and client) are always free to back off the transaction if the terms are not acceptable, so only a problem if the signer blindly follows orders.

One serious downside is that a server can reject a message by stating its' required parameters, but a client doesn't have the same capability. If a response is inadequately signed, especially for a non-idempotent action - what then?

[ioggstream]

FYI Accept-Signature work is ongoing on https://github.com/WICG/webpackage/blob/master/draft-yasskin-httpbis-origin-signed-exchanges-impl.md#the-accept-signature-header--accept-signature

Syntax is based on structured headers.

[liamdennehy]

As @msporny has implied, there is a risk this ends up bloating the specification into a negotiation protocol, while there is value in keeping this simple. Implementing a full negotiation process may be too much and hinder adoption, so we'd rely on signature producers communicating this out-of-band for now. If this is a real need, we can propose an extension to this specification at a later time, but for now I don't think it is a core feature.

[ioggstream]

Ok for a differenti I-D. In case we should plan it soob to be sure of being consistent