Re: combined field value, Re: Working Group Last Call: draft-ietf-httpbis-message-signatures-13

On Oct 31, 2022, at 10:40 AM, Julian Reschke <julian.reschke@gmx.de<mailto:julian.reschke@gmx.de>> wrote:

Am 31.10.2022 um 15:33 schrieb Justin Richer:
Hi Julian, thanks for this writeup of this issue. Multiple-valued fields have been potentially trouble from the start of this work many years ago.

After re-reading the text in RFC9110 section 5, but especially 5.3, the normalization rules are consistent with the advice of " For consistency, use comma SP”, but an intermediary could in fact combine field values without spaces on the way through. I think what we want to do is something like:


HTTP fields that are known to be  "list-based fields” by the signer or verifier which have multiple values MUST have all values combined using the delimiter of “comma <SP>” as suggested by RFC9110. <warning about set-cookie goes here>

So it’s still the “combined value” but it’s got very specific rails around it. What do you think of this approach?

I agree that we might want to revisit this text in the HTTP semantics document, too. In my own limited practical experience, whenever the libraries I’ve used offer a pre-combined value, it always does the combination with “comma <SP>”, as shown in both examples and in the non-normative recommendations. I think that the fact that the examples do the same, in spite of the normative text technically allowing other options, is a practical consideration for implementors.

 — Justin

Well, there's nothing in the spec that guarantees that this (adding the
OPTIONAL SP) will happen. I'm not sure it's a good idea to rely on it.

A sender can always make things robust by making sure that there's only
a single instance of the field...

Best regards, Julian


I agree exactly with this — sorry if what I was saying before was unclear. I think it’s in fact MORE important to call out because things will “just work” in the wild for so many developers that having imprecise behavior is a huge problem. It would perhaps be worth adding implementation considerations for this issue in Signatures, and eventually revisiting the requirements in HTTP.

Making a completely robust solution here is not out of the question — you’d just need to take every list-based field, parse it to pull out the comma-separated values, and re-combine it. I don’t think we want to require that by all Signatures implementations though: you could get your list of list-based fields wrong, you could have a problem with your parser that grabs quoted commas, etc. But calling it out for implementations that want to cover all corner cases, that makes sense to me. We do something similar for obs-fold already.

The good news, from a security perspective, is that this problem does at least fail closed — what would otherwise be a valid message will have a failing signature. Not great, but at least not causing the opposite problem of having a manipulated message pass with what should be a failing signature.

 — Justin