Re: Signing Set-Cookie

[Martin Thomson <[e-mail]>]

Hey Justin,

I don't agree that this is an acceptable way of dealing with this problem.  It makes the content under signature malleable.  Even if that is extremely narrowly applicable, I don't see how we could publish a specification where the only defense against an attack like this is text to the effect of "this might happen".

On Tue, Jun 7, 2022, at 06:50, Justin Richer wrote:
> What I’ve done is create a new security consideration for this, and 
> discussing how it might possibly lead to the foothold for an attack.
>
> https://github.com/httpwg/http-extensions/pull/2143/files#diff-1d57bca6223a0fee3ef29148c2550c0f862e72f67a56cc7f57b5a72fbd8320e3R1802
>
> — Justin
>
>> On Jun 1, 2022, at 7:58 PM, Martin Thomson <[e-mail]> wrote:
>> 
>> 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 
>>> potentially problematic enough that this should be given more 
>>> consideration.
>>> 
>>> On Wed, Jun 1, 2022 at 2:39 PM Justin Richer <[e-mail]> 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
>>