Subject: Signing Set-Cookie

From: Justin Richer <[email-masked]>
Date: Wed, 1 Jun 2022 17:36:35 -0400

The Set-Cookie header syntax is weird in that it doesn’t allow for concatenation in the normal List syntax. The Signature spec relies on this concatenation for the combination of values of headers that show up multiple times. This discrepancy is called out in this issue:

https://github.com/httpwg/http-extensions/issues/1183 <https://github.com/httpwg/http-extensions/issues/1183>

However, on further investigation, I don’t think this actually causes a problem. The concatenation process outlined in Signatures still works on multiple Set-Cookie values, the only weird thing is that the RESULT of that process cannot itself be parsed as a valid Set-Cookie header. 

But the thing is, it doesn’t have to be parsed. It just has to exist as a string in the signature base, and be re-created by both signer and verifier in a consistent way. 

I’m planning on closing this issue with a note in the appropriate section of the signature spec, but if there’s something I’m missing about this, please chime in.

 — Justin

---

From: Nick Harper <[email-masked]>
Date: Wed, 1 Jun 2022 16:20:37 -0700

A Set-Cookie header could have a comma in it (e.g. in the Expires= or Path=
parts), which means that it's probably possible for two different
combinations of Set-Cookie headers to be concatenated/canonicalized to the
same value. I'm not certain there's an attack here, but this seems
potentially problematic enough that this should be given more consideration.

On Wed, Jun 1, 2022 at 2:39 PM Justin Richer <[email-masked]> wrote:

> The Set-Cookie header syntax is weird in that it doesn’t allow for
> concatenation in the normal List syntax. The Signature spec relies on this
> concatenation for the combination of values of headers that show up
> multiple times. This discrepancy is called out in this issue:
>
> https://github.com/httpwg/http-extensions/issues/1183
>
> However, on further investigation, I don’t think this actually causes a
> problem. The concatenation process outlined in Signatures still works on
> multiple Set-Cookie values, the only weird thing is that the RESULT of that
> process cannot itself be parsed as a valid Set-Cookie header.
>
> But the thing is, it doesn’t have to be parsed. It just has to exist as a
> string in the signature base, and be re-created by both signer and verifier
> in a consistent way.
>
> I’m planning on closing this issue with a note in the appropriate section
> of the signature spec, but if there’s something I’m missing about this,
> please chime in.
>
>  — Justin
>

---

From: "Martin Thomson" <[email-masked]>
Date: Thu, 02 Jun 2022 09:58:56 +1000

Yeah, what Nick said.

Cookie concatenation has a special carve-out in all HTTP versions past 1.x; I see no real harm in making another for Set-Cookie.

On Thu, Jun 2, 2022, at 09:20, Nick Harper wrote:
> A Set-Cookie header could have a comma in it (e.g. in the Expires= or 
> Path= parts), which means that it's probably possible for two different 
> combinations of Set-Cookie headers to be concatenated/canonicalized to 
> the same value. I'm not certain there's an attack here, but this seems