Subject: #1207: Signature Negotiation and Want-Signature

From: Justin Richer <[email-masked]>
Date: Fri, 23 Jul 2021 16:52:44 -0400

The editors of the signatures draft are looking at what it would take to add a negotiation feature to the Message Signatures draft, as it’s been requested a number of times and tracked specifically in http-extensions issue #1207. I want to give our rough strawman here and gather feedback, which we’ll then incorporate into a more concrete PR. None of this is meant to be spec-level text, but we’re looking for feedback on the approach, applicability, and extent of this feature.

We’re proposing a “Want-Signature” header that can be used in both requests and responses. The value of this header is a Dictionary structured field, mimicking the “Signature-Input” header’s contents today, using named signature identifiers as keys and signature parameters structures as values (note that these are defined as inner-lists with named parameters). The sender of the Want-Signature header would need to choose a signature identifier for each included element.

When used in a request, the Want-Signature header indicates that the client wants the server to sign the response using the signature parameters. The server should (must?) sign all of the listed identifiers, using the identified key and algorithm if present. The resulting signature should (must?) be returned using the same signature identifier as in the request. The client can here indicate identifiers that bind the response to the request, including the @request-response identifier (recently added in the editors copy[2], if you haven’t seen it). 

When used in a response, the Want-Signature header indicates that the server wants the client to sign its :next: request using the signature parameters. The client should (must?) sign all of the listed identifiers, using the identified key and algorithm if present. The resulting signature should (must?) be presented using the same signature identifier as in the response header in the next request.

A responder on either end can always send multiple signatures, one that meets requested parameters and one that might not (signs more, signs less, uses different algorithms, uses different keys, etc). It will always be up to the receiver of a signature to determine if the signature meets their needs, regardless of what was requested.

A few core open questions we aren’t sure on (or, quite frankly, the editors disagree on where to start):

- When multiple values are sent, is this an AND or an OR of parameters? Do I have to send something that fits only one, or one for each, or one for all of them, or … ?
- Could a signature response include additional fields as opposed to just what’s listed? So let’s say I ask for (a b c), is it OK if I get (a b c d) in response? Ordering of the signed elements isn’t an issue here with how signatures are generated, more an issue of set math.
 - Similarly, what about parameters on the signed request? Can I fill in a “keyid" if none is specified? What about “alg”? I would assume “created” would always be added. Could I substitute a parameter value?
 - How do we handle error conditions if the responder is unable to fulfill the parameters of the requested signature? Should this be handled with an all out error or could we reply “successfully” but have a separate signature that doesn’t meet parameters?
 - Bikeshedding: should this be Want-Signature? Accept-Signature? Really-Need-You-To-Sign-This?

And finally this brings up another higher-level question: how does this align with, or possibly subsume, the http-origin-signed-responses[3] work from WEBPACK? Now that Message Signatures more properly covers responses and has clearer algorithm and key identifiers, the kinds of signed exchange defined in that draft are more able to be expressed using Message Signatures. This “Want-Signature” element is perhaps the last missing piece, as the WEBPACK proposal defines an “Accept-Signature” header with similar functions.

Thanks,

 — Justin

[1] https://github.com/httpwg/http-extensions/issues/1207 <https://github.com/httpwg/http-extensions/issues/1207>
[2] https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#section-2.3.11 <https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#section-2.3.11>
[3] https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html <https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html>

---

From: [email-masked]
Date: Wed, 28 Jul 2021 00:31:37 +1200

On 2021-07-24 08:52, Justin Richer wrote:
> The editors of the signatures draft are looking at what it would take
> to add a negotiation feature to the Message Signatures draft, as
> it’s been requested a number of times and tracked specifically in
> http-extensions issue #1207. I want to give our rough strawman here
> and gather feedback, which we’ll then incorporate into a more
> concrete PR. None of this is meant to be spec-level text, but we’re
> looking for feedback on the approach, applicability, and extent of
> this feature.
> 

FWIW, I support the spec containing this feature. It is always nice to 
have a spec to follow instead of having to deal with interoperability 
problems caused by ad-hoc developer ideas.

> - When multiple values are sent, is this an AND or an OR of
> parameters? Do I have to send something that fits only one, or one for
> each, or one for all of them, or … ?

I propose that the values are independent. So that an agent can require 
one signature, and offer to accept others for better cross-validation if 
provided.

I can forsee some corporate/national policy requiring algorithm A which 
is outdated/insecure trying to operate in a world that has migrated to 
some better algorithm B already. Giving developers and admin the ability 
to say "require A, also check B"

> - Could a signature response include additional fields as opposed to
> just what’s listed? So let’s say I ask for (a b c), is it OK if I
> get (a b c d) in response?

IMO that should be a clear MUST NOT.

Since (d) was not suggested to be part of the signature there is no way 
for intermediaries to know that they MUST NOT alter its value. One 
should thus expect (d) to be different in recipient and sender views of 
the world. As a result, any signature they try to calculate from their 
different values can only be expected to mismatch.

> Ordering of the signed elements isn’t an
> issue here with how signatures are generated, more an issue of set
> math.
>  - Similarly, what about parameters on the signed request? Can I fill
> in a “keyid" if none is specified? What about “alg”? I would
> assume “created” would always be added. Could I substitute a
> parameter value?
>  - How do we handle error conditions if the responder is unable to
> fulfill the parameters of the requested signature? Should this be
> handled with an all out error or could we reply “successfully” but
> have a separate signature that doesn’t meet parameters?

I propose that it may be useful to define both Accept-* and Want-* 
header names (or whatever equivalents) to manage the optional vs 
mandatory difference in use-cases of security vs transmission 
correctness validation.

  * Accept-Signature being an OPTIONAL sign. Sender SHOULD/MAY/ought-to 
sign using this signature pattern, but recipient(s) will not reject 
messages that lack it simply because of that lack.
   As a bonus intermediaries can add these if they want validation across 
certain hops.

  * Want-Signature being MUST sign. Recipient MUST reject the message if 
the signature is not provided. MUST NOT be touched by intermediaries.

> And finally this brings up another higher-level question: how does
> this align with, or possibly subsume, the
> http-origin-signed-responses[3] work from WEBPACK? Now that Message
> Signatures more properly covers responses and has clearer algorithm
> and key identifiers, the kinds of signed exchange defined in that
> draft are more able to be expressed using Message Signatures. This
> “Want-Signature” element is perhaps the last missing piece, as the
> WEBPACK proposal defines an “Accept-Signature” header with similar
> functions.
> 
> Thanks,
> 
>  — Justin
> 
> [1] https://github.com/httpwg/http-extensions/issues/1207
> [2]
> https://httpwg.org/http-extensions/draft-ietf-httpbis-message-signatures.html#section-2.3.11
> [3]
> https://wicg.github.io/webpackage/draft-yasskin-http-origin-signed-responses.html

AYJ

---

From: Justin Richer <[email-masked]>
Date: Thu, 29 Jul 2021 12:08:36 -0400

Thanks for the response. Trimming this thread down as I’d like to understand more about this point:

> I propose that the values are independent. So that an agent can require one signature, and offer to accept others for better cross-validation if provided.
> 
> I can forsee some corporate/national policy requiring algorithm A which is outdated/insecure trying to operate in a world that has migrated to some better algorithm B already. Giving developers and admin the ability to say "require A, also check B”
> 

It seems like you’re saying we should have some kind of flag that marks a given signature request set as “required”, and otherwise all elements are “OR”’d with each other. Is that it? So if I sent:

	Want-Signature: sig1=(a b c);alg=bad-rsa;required, sig2=(a b d);alg=other-rsa

Then a responder could send back:

	Signature-Input: sig1=(a b c);alg=bad-rsa;key-id=legacy-key, sig3=(c d e);alg=new-fancy-ec

And that would be acceptable. But if it sent back:

	Signature-Input: sig2=(a b d);alg=other-rsa;key-id=legacy-key, sig3=(c d e);alg=new-fancy-ec

This would be not acceptable because it’s missing the “required” input even though it covers the other signature in the request. Both of them add their own separate non-specified signature and that’s fine. Am I reading this right?

Along these lines, whether or not I’m understanding this suggestion, could you please give a couple examples of the kind of syntax you’d expect to see for this, with your ideas on how they’d be interpreted?

 — Justin