Re: Delete-Cookie header??

I (belatedly) whipped together an I-D for this:
https://yoavweiss.github.io/delete-cookie/draft-deletecookie-weiss-http.html

I'd love y'all's thoughts (and issues).

On Sun, Nov 3, 2024 at 6:41 PM Watson Ladd <watsonbladd@gmail.com> wrote:

> Personally I don't think changes to the security model of cookies are a
> good idea. This should just be a different way to name cookies that you
> already could have set.
>
> On Sun, Nov 3, 2024 at 2:20 AM Patrick Meenan <patmeenan@gmail.com> wrote:
>
>> Specifically, the request was to use the same bounds already in place for
>> set-cookie. Registerable domain 1 should not have access to registerable
>> domain 2.
>>
>> Multiple domains within a given registerable domain where set-cookie can
>> already access is the discussion point.
>>
>> On Sun, Nov 3, 2024 at 3:12 AM רועי ברקאי <roybarkayyosef@gmail.com>
>> wrote:
>>
>>> So It shall be documented that domain1 should not have access to delete
>>> domain2 .
>>>
>>> On Sun, Nov 3, 2024, 09:57 Yoav Weiss <yoav@yoav.ws> wrote:
>>>
>>>>
>>>>
>>>> On Sat, Nov 2, 2024, 21:41 רועי ברקאי <roybarkayyosef@gmail.com> wrote:
>>>>
>>>>> Hey Steven
>>>>>
>>>>> For special SaaS you as the provider don't know the coockie name,
>>>>> same for wix for example.
>>>>>
>>>>> Secondly in regards to damain1.com on domain2.com the functionality
>>>>> is desired by yoav ,
>>>>>
>>>>
>>>> It really isn't
>>>>
>>>> I wish to have a security feature for that to mitigate potential risk
>>>>>
>>>>
>>>>> On Sat, Nov 2, 2024, 21:05 Steven Bingler <bingler@google.com> wrote:
>>>>>
>>>>>> > as a parent domain may...attempt to delete any other domain cookie
>>>>>>
>>>>>> This is already possible and is in fact nearly trivial if a human
>>>>>> looks at their browser's developer tools to obtain the domain and path of
>>>>>> the cookie they want to delete. No guessing required.
>>>>>>
>>>>>> > Also some enterprises hold domain1.com and domain2.com and might
>>>>>> wish for domain1.com to delete domain2.com cookie this should be
>>>>>> allowed with relevant security features
>>>>>>
>>>>>> It's not currently possible for one registrable domain to target and
>>>>>> delete cookies of another registrable domain and I don't believe this
>>>>>> proposal is advocating for that ability.
>>>>>>
>>>>>> - Steven
>>>>>>
>>>>>>
>>>>>> ‪On Fri, Nov 1, 2024 at 5:46 PM ‫רועי ברקאי‬‎ <
>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>
>>>>>>> well the thing is it does introduce new functionality as a parent
>>>>>>> domain may/ any other domain attempt to delete any other domain cookie in
>>>>>>> the current suggestion.
>>>>>>> I believe the current edit rights are abusive and many supply chain
>>>>>>> attack are carried with that.
>>>>>>> by lowering the complexity the attack would be more common and the
>>>>>>> options would larger for different domains.
>>>>>>> Also some enterprises hold domain1.com and domain2.com and might
>>>>>>> wish for domain1.com to delete domain2.com cookie this should be
>>>>>>> allowed with relevant security features
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Fri, 1 Nov 2024 at 22:38, Steven Bingler <bingler@google.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi All,
>>>>>>>>
>>>>>>>> Browsers will send any cookies that a given request has access to
>>>>>>>> (i.e.: domain, path, secure-ness), meaning that any server that receives
>>>>>>>> these cookies also already has write access to all those cookies.
>>>>>>>>
>>>>>>>> Since the purpose of this proposal is to target “cookie crust” then
>>>>>>>> these are presumably cookies the server is receiving from the client. So,
>>>>>>>> imo, it follows that a `Delete-Cookie: foo` request should delete any
>>>>>>>> cookies that match the name “foo” regardless of their domain/path. Perhaps
>>>>>>>> this could be made more precise and require both the cookie’s name and
>>>>>>>> value to limit collateral damage?
>>>>>>>>
>>>>>>>> This isn’t dangerous as it doesn’t introduce new behavior, it’s
>>>>>>>> just a convenience so the server doesn’t have to guess all applicable
>>>>>>>> domain/path combinations (well, it could be a footgun). Any hosts worried
>>>>>>>> about malicious sub/super-domains should consider the public suffix list as
>>>>>>>> Yoav mentioned.
>>>>>>>>
>>>>>>>> But I question how useful this is and whether it’s worth the added
>>>>>>>> complexity. 6265bis has a requirement that all UAs limit the longest
>>>>>>>> specifiable expiry of a cookie to 400 days in the future. Chrome has had
>>>>>>>> this behavior for a couple of years now meaning that any orphaned cookies
>>>>>>>> with far-reaching expiry dates have since been deleted. It’s possible that
>>>>>>>> some orphaned session cookies still exist but Chrome and other UAs have
>>>>>>>> methods for deleting those as well.
>>>>>>>>
>>>>>>>> Given all that I believe it’s increasingly less likely for a server
>>>>>>>> to see any “cookie cruft” after a ~year and so I’m leaning against the
>>>>>>>> creation of a `Delete-Cookie` header given the complexity/usefulness
>>>>>>>> tradeoff.
>>>>>>>>
>>>>>>>> - Steven
>>>>>>>>
>>>>>>>> On Thu, Oct 31, 2024 at 11:53 PM Yoav Weiss <yoav.weiss@shopify.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> It seems to me that it would make sense to mirror the domain-based
>>>>>>>>> scope of cookies here.
>>>>>>>>> That is - if you can get these cookies in requests to your origin,
>>>>>>>>> you can also delete them.
>>>>>>>>>
>>>>>>>>> So, if b.example.com have set domain-wide cookies on example.com,
>>>>>>>>> a.example.com would be able to delete them. But it wouldn't be
>>>>>>>>> able to delete host-specific cookies for b.example.com. Does that
>>>>>>>>> make sense?
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On Thu, Oct 31, 2024 at 6:18 PM Rory Hewitt <rory.hewitt@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>>> Yeah, the existing clear-site functionality has a big security
>>>>>>>>>> risk and massive blast radius.
>>>>>>>>>>
>>>>>>>>>> My thinking on subdomains is that if you own "
>>>>>>>>>> customer1.saasprovider.com" (and potentially own subdomains
>>>>>>>>>> within that, e.g. "d999.customer1.saasprovider.com") then there
>>>>>>>>>> is certainly the possibility that, for reasons fair or foul, your landlord
>>>>>>>>>> ("saasprovider.com") may send "Delete-Cookie:
>>>>>>>>>> abc;subDomains=true" and as a result *your* "abc" cookie in
>>>>>>>>>> *your* "customer1.saasprovider.com" domain is deleted, along
>>>>>>>>>> with the "abc" cookie in the "saasprovider.com" domain and maybe
>>>>>>>>>> other subdomains.
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Arguably, saasprovider.com should be on the PSL
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> But...
>>>>>>>>>>
>>>>>>>>>> Presumably your landlord isn't malicious, so either this scenario
>>>>>>>>>> would happen because they're hacked or they make a stupid mistake. These
>>>>>>>>>> things obviously do happen, but is that reason enough to not allow
>>>>>>>>>> otherwise useful functionality. We're talking about cookies being deleted,
>>>>>>>>>> which is a low-ish risk, no?
>>>>>>>>>>
>>>>>>>>>> We could, of course limit this to certain cookies - perhaps no
>>>>>>>>>> "Sec-*" cookies or those without the "Secure" attribute or to those which
>>>>>>>>>> have a domain implicitly (i.e. it wasn't included when the original
>>>>>>>>>> Set-Cookie header was sent to create it.)
>>>>>>>>>>
>>>>>>>>>> To me, the benefits of allowing this subdomain functionality
>>>>>>>>>> outweigh the drawbacks. But that's just me.
>>>>>>>>>>
>>>>>>>>>> ‪On Thu, Oct 31, 2024 at 9:38 AM ‫רועי ברקאי‬‎ <
>>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>>
>>>>>>>>>>> A better mechanism for the clear-site-data would be
>>>>>>>>>>> to
>>>>>>>>>>> 1.delete only subdomains cookies that also hold that flag
>>>>>>>>>>> (allow-parent domain-deletion=true)
>>>>>>>>>>> 2.where the subdomain cookie has a list of domains allowed to
>>>>>>>>>>> delete this cookie.
>>>>>>>>>>> 3.a request should be sent to the subdomain web server to
>>>>>>>>>>> approve that  in which the approval logic would be on the subdomain server
>>>>>>>>>>> side.
>>>>>>>>>>>
>>>>>>>>>>> The same 3 suggested solutions are also security architectures
>>>>>>>>>>> for the feature you suggested (Yoav, Rory).
>>>>>>>>>>> That way you may add a parent to subdomain deletion without the
>>>>>>>>>>> risk of supply chain attack as that behavior is implemented by the
>>>>>>>>>>> subdomain.
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> ‪On Thu, 31 Oct 2024 at 18:18, ‫רועי ברקאי‬‎ <
>>>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>>>
>>>>>>>>>>>> Dear Patrick,
>>>>>>>>>>>>
>>>>>>>>>>>> You are correct that risk is also available in that sense as
>>>>>>>>>>>> well.
>>>>>>>>>>>> But two wrongs don't make a right. Do you believe this
>>>>>>>>>>>> supply chain risk is irrelevent?
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On Thu, 31 Oct 2024 at 18:13, Patrick Meenan <
>>>>>>>>>>>> patmeenan@gmail.com> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> I agree in principle to subdomains-only, but wouldn't the
>>>>>>>>>>>>> risks called-out also be a problem with clear-site-data which wipes out all
>>>>>>>>>>>>> cookies (including parent and horizontally to peers)?
>>>>>>>>>>>>>
>>>>>>>>>>>>> ‪On Thu, Oct 31, 2024 at 12:02 PM ‫רועי ברקאי‬‎ <
>>>>>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Rory please read my response.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I agree with Rorry on most of the solution.
>>>>>>>>>>>>>> I believe an issue may be rissen when an authority
>>>>>>>>>>>>>> example.com may delete a cookie for a.example.com may have
>>>>>>>>>>>>>> supply chain attack vector possibilities therefore im against that solution.
>>>>>>>>>>>>>> As a tennant of a domain (owner of a subdomain) I wouldnt
>>>>>>>>>>>>>> want my landlord ie the domain the company I buy services from to delete
>>>>>>>>>>>>>> the cookies of my users.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Take in mind that many subdomains that uses SAAS have their
>>>>>>>>>>>>>> scripts run as well from the parent domain. therefore a supply chain/DOS
>>>>>>>>>>>>>> attack may take place via removing access to users by deleting their
>>>>>>>>>>>>>> cookies.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On Thu, 31 Oct 2024 at 17:45, Rory Hewitt <
>>>>>>>>>>>>>> rory.hewitt@gmail.com> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Since the "Delete-Cookie: abc, def" is a response header,
>>>>>>>>>>>>>>> then if sent from a server at e.g. bob.example.com, I would
>>>>>>>>>>>>>>> expect it to only delete the "abc" and "def" cookies in the
>>>>>>>>>>>>>>> bob.example.com subdomain. Allowing even a higher iste
>>>>>>>>>>>>>>> (i.e. clearing the "abc" and "def" cookies at the
>>>>>>>>>>>>>>> example.com root domain seems very dangerous. In a
>>>>>>>>>>>>>>> federated world, we have things like "
>>>>>>>>>>>>>>> customer1.saasprovider.com" who is completely unrelated to "
>>>>>>>>>>>>>>> customer2.saasprovider.com", and I wouldn't want either of
>>>>>>>>>>>>>>> them to to be able to delete cookies at the "
>>>>>>>>>>>>>>> saasprovider.com" root domain, since they could have been
>>>>>>>>>>>>>>> placed there by either customer.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> However, allowing "Delete-Cookie: abc, def" sent from
>>>>>>>>>>>>>>> bob.example.com to be able to delete those cookies from
>>>>>>>>>>>>>>> both bob-example.com and all *.bob.example.com subdomains
>>>>>>>>>>>>>>> seems more reasonable, IF one assumes that the
>>>>>>>>>>>>>>> bob.example.com server in some way 'controls' its
>>>>>>>>>>>>>>> subdomains.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> In short, the only thing that should be able to delete
>>>>>>>>>>>>>>> cookies from a domain is a Delete-Cookie header sent from that domain or a
>>>>>>>>>>>>>>> 'higher' (closer to root) domain.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Of course, the header could be enhanced in a similar way to
>>>>>>>>>>>>>>> HSTS:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Delete-Cookie: abc, def;subDomains. ghi"
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> indicating that (if sent from bob.example.com), the
>>>>>>>>>>>>>>> following cookies should be deleted:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> * "abc" if it has a Domain of bob.example.com domain
>>>>>>>>>>>>>>> * "def" if it  has a Domain of bob.example.com domain or
>>>>>>>>>>>>>>> any subdomains of bob.example.com
>>>>>>>>>>>>>>> * "ghi" if it has a Domain of bob.example.com domain
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> But that's getting into more complexity that maybe isn't
>>>>>>>>>>>>>>> necessary.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On Thu, Oct 31, 2024 at 4:55 AM Patrick Meenan <
>>>>>>>>>>>>>>> patmeenan@gmail.com> wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I'm assuming the scope would be similar to clear-site-data:
>>>>>>>>>>>>>>>> "cookies" where, at least in w3c land, it clears across all of the
>>>>>>>>>>>>>>>> subdomains in the "registered domain" (
>>>>>>>>>>>>>>>> https://www.w3.org/TR/clear-site-data/#clear-cookies),
>>>>>>>>>>>>>>>> just with the ability to target a specific name instead of nuking
>>>>>>>>>>>>>>>> everything.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Should it be limited to the direct hierarchy or should it
>>>>>>>>>>>>>>>> also impact same-level origins like clear-site-data does? i.e.
>>>>>>>>>>>>>>>> bob.example.com clears from bob.example.com and example.com
>>>>>>>>>>>>>>>> but should it be able to target deleting from
>>>>>>>>>>>>>>>> alice.example.com?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On Thu, Oct 31, 2024 at 6:57 AM Yoav Weiss <
>>>>>>>>>>>>>>>> yoav.weiss@shopify.com> wrote:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> ‪On Thu, Oct 31, 2024 at 11:49 AM ‫רועי ברקאי‬‎ <
>>>>>>>>>>>>>>>>> roybarkayyosef@gmail.com> wrote:‬
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> As a first party coockie holder you may set an expiration
>>>>>>>>>>>>>>>>>> date on the coockie you have created.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Sure, but since setting an expiration date requires
>>>>>>>>>>>>>>>>> predicting the future, we need a way to correct past predictions that
>>>>>>>>>>>>>>>>> didn't quite work out.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Allowing cross site coockie deletion would enable issues
>>>>>>>>>>>>>>>>>> for users as an attacker may remove all mostly used coockie names
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Can you expand on that? I wouldn't expect a server to be
>>>>>>>>>>>>>>>>> able to delete cookies that it can't receive, if that makes sense.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On Thu, Oct 31, 2024, 12:39 Yoav Weiss <
>>>>>>>>>>>>>>>>>> yoav.weiss@shopify.com> wrote:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> On Thu, Oct 31, 2024 at 11:15 AM Daniel Stenberg <
>>>>>>>>>>>>>>>>>>> daniel@haxx.se> wrote:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> On Thu, 31 Oct 2024, Yoav Weiss wrote:
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> > `Delete-Cookie: name1, name2` as an example syntax,
>>>>>>>>>>>>>>>>>>>> which seems simple
>>>>>>>>>>>>>>>>>>>> > enough and can get the job done.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> Since cookies are hierchical, it should probably be
>>>>>>>>>>>>>>>>>>>> noted that this list
>>>>>>>>>>>>>>>>>>>> identifying 'name1' and 'name2' can in fact match
>>>>>>>>>>>>>>>>>>>> numerous cookies (for
>>>>>>>>>>>>>>>>>>>> different paths), not just two and there is no way for
>>>>>>>>>>>>>>>>>>>> this syntax to delete
>>>>>>>>>>>>>>>>>>>> just a subset of them.
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> That's true. At the same time, the use case at hand is
>>>>>>>>>>>>>>>>>>> one where we want to delete cookies when we have no knowledge of their path.
>>>>>>>>>>>>>>>>>>> So I believe it's fine to delete all matching cookies.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> +Colin Bendell <colin.bendell@shopify.com> to keep me
>>>>>>>>>>>>>>>>>>> honest, as he's closer to this work.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>   / daniel.haxx.se
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> --
>>>>>>>>>>>>>>> Rory Hewitt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://www.linkedin.com/in/roryhewitt
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> --
>>>>>>>>>> Rory Hewitt
>>>>>>>>>>
>>>>>>>>>> https://www.linkedin.com/in/roryhewitt
>>>>>>>>>>
>>>>>>>>>
>
> --
> Astra mortemque praestare gradatim
>