- From: Martin Thomson <mt@lowentropy.net>
- Date: Thu, 02 Jun 2022 09:58:56 +1000
- To: ietf-http-wg@w3.org
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 <jricher@mit.edu> 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
Received on Wednesday, 1 June 2022 23:59:27 UTC