Re: Signing Set-Cookie

On Jun 7, 2022, at 2:27 AM, Willy Tarreau <w@1wt.eu> wrote:
> 
> On Tue, Jun 07, 2022 at 08:28:08AM +1000, Martin Thomson wrote:
>> 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".
> 
> Agreed. Signed contents may never be trusted more than the algorithm
> used to sign them. If you start by not trusting the algorithm, it's not
> by suggesting to be extra careful with the contents that we can deal
> with this. And the use of the signature is here precisely to help an
> implementation know if it may or may not trust the contents, so that
> would completely defeat the purpose.
> 

The signing algorithm is a separate dimension than the signature base generation algorithm (ie, what to sign). I completely agree that if you don’t trust your signing algorithm (beit from collision attacks or key distribution problems or other problems), then you can’t trust what you’re signing. It is not the goal of this specification to solve that problem for applications — nor should it be.

While I agree that the combination could potentially be problematic, and definitely is distasteful from a security purity standpoint, what I’m not seeing is an attack where two distinct non-theoretical valid values of Set-Cookie could be combined into another valid Set-Cookie header. Yes in theory there’s a comma in the syntax, but I’m not seeing how that could be used to mount an actual attack in a meaningful way. The two Set-Cookie headers combined would need to have the exact same content as the single Set-Cookie header on its own, but be interpreted in a different way by the verifier in such a way that would affect the application. The attacker here isn’t substituting a completely different value, and is not adding a value where one wasn’t before. Can someone please give me a concrete demonstration that shows this is something we should actually protect against and not just something to warn against?

Regardless, what is the recommended approach? Martin’s seems to be “throw out HTTP Signatures entirely”, but he’s said that since the work started. :) What I think though is that we’ve got a few potential approaches:

 - Never sign Set-Cookie
 - Never sign multiple Set-Cookie headers
 - Have a special syntax for dealing with Set-Cookie (probably a derived component, but I’m not thrilled about this one)
 - Warn against weirdness with multiple Set-Cookie headers

Any other approaches?

 — Justin