Re: Signing Set-Cookie

All,

I’ve pushed updated language to the security considerations, including more comprehensive discussion of the issue with internal commas. 

I’ve raised a separate issue to track a proposal for allowing wrapped encoding of problematic field values:

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

Functionally, this proposal turns each field line into a ByteSequence and the combination into a List, and the whole thing gets serialized as a strict List value.

What I like about this proposed approach is that it’s applicable across all different fields, regardless of the input itself. If an application wants to do this all throughout, it can.

 — Justin

> On Jun 8, 2022, at 12:22 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> I disagree that my attitude will lead to disaster — and in fact think quite the opposite, it will avoid disaster — but I appreciate your stance.
> 
> The escaping transformation is an interesting idea, and could actually be applied to more than just set-cookie.
> 
> We already have a flag that transforms the value, `sf`, and so another flag, `enc` or `b64` is not out of the question. Then the recommendation/requirement would be to use this flag with Set-Cookie and similar fields to avoid this problem.
> 
> Before someone asks: No, I do not think this is a good idea to apply to all field values by default.
> 
> What do folks think of this?
> 
> — Justin
> 
>> On Jun 7, 2022, at 7:34 PM, Watson Ladd <watsonbladd@gmail.com> wrote:
>> 
>> On Tue, Jun 7, 2022 at 10:35 AM Justin Richer <jricher@mit.edu> wrote:
>>> 
>>> 
>>> 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?
>> 
>> This is the attitude that leads to disaster. Clever attackers will
>> find ways in which the assumptions underlying the analysis of the
>> harmlessness of the confusion are broken. Its much easier to design
>> things to be injective and thus never have to worry, than to have to
>> ask about the construction of cookie values each and every time a user
>> uses them. This isn't "security purity", it's what's required to
>> ensure that users are safe, without having to understand and get the
>> details right each and every time. We've learnt these lessons the hard
>> way, and it's disappointing to see them get ignored.
>> 
>>> 
>>> 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?
>> 
>> Apply an escaping transformation or some sort of base64 before turning
>> into a List.
>> 
>>> 
>>> — Justin
>> 
>> 
>> 
>> --
>> Astra mortemque praestare gradatim
> 
>