Re: Signing Set-Cookie

[Watson Ladd <[e-mail]>]

This would also apply to treating MAC as a Signature wouldn't it?

On Mon, Jun 6, 2022, 3:31 PM Martin Thomson <[e-mail]> 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".
>
> 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
> >>
>
>