Re: Signing Set-Cookie

I’ve put together a PR that will hopefully add one small tool to put away this, and similar, issues:

https://github.com/httpwg/http-extensions/pull/2189


It essentially does what the issue proposed: create a new flag that has you wrap each distinct field value as a Byte Sequence and put that into a List, then serialize the List using strict serialization rules from Structured Fields. It is applicable to any field, but it’s really meant for problematic things like Set-Cookie. I could have used a String Item, but decided on a Byte Sequence to have more robust armoring against any other fields out there in the wild that might be weird.

Please take a look. We plan to have a new revision ahead of IETF114 and I hope to include this or put it firmly out of scope.

 — Justin

On Jun 17, 2022, at 4:58 PM, Justin Richer <jricher@mit.edu<mailto:jricher@mit.edu>> wrote:

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


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<mailto: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<mailto:watsonbladd@gmail.com>> wrote:

On Tue, Jun 7, 2022 at 10:35 AM Justin Richer <jricher@mit.edu<mailto: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