Re: Cookie controls?

Regarding alternatives, what are the constraints that prevent you from
putting the CDN domain on the public suffix list (https://publicsuffix.org)?
AFAIK many sites which have registrable domains with subdomains hosting
user-controlled content use the PSL to prevent the cookie clashes you're
talking about -- some prominent examples include appspot.com, blogspot.com
and github.io.

Cheers,
-Artur

On Fri, Aug 17, 2018 at 12:38 AM Mike West <mkwst@google.com> wrote:

> To answer Yoav's questions:
>
> 1.  I stopped working on CSP's cookie controls because I thought it would
> be folded into Feature Policy. That didn't happen.
> 2.  There are no alternatives that I know of which give you the guarantees
> you're looking for. Perhaps we should build some.
>
> This seems like a reasonable kind of problem to address, but if we build
> something, let's not put it into CSP. I'm very interested in calling CSP3
> done, and never touching it again. :) Erik's `Limit-Cookies` header sounds
> fine (I'd prefer for it to live in origin policy, actually, but that's
> something of a mid-term project in itself).
>
> Dev's suggestion that we lean on prefixes sounds reasonable to me. That
> is, the limits we express could be prohibitions against sending/setting
> non-prefixed cookies (or setting cookies at all). I'd caution against
> saying that we could "constrain cookies to the Origin model", though:
> cookies don't respect ports, and given the not-terribly-enthusiastic
> response that https://tools.ietf.org/html/draft-west-origin-cookies-01
> got, I expect that `__Host-` is going to be the best that we can do.
>
> -mike
>
>
> On Fri, Aug 17, 2018 at 6:44 AM Devdatta Akhawe <dev.akhawe@gmail.com>
> wrote:
>
>> Not sure I understand. Javascript can't set a __Host cookie that is
>> broader context than the current host either. Do you want to do this for
>> applications where changing the application to use __Host cookies is not
>> possible (and thus, you want a header that can be added by a proxy in the
>> middle)?
>>
>> Also, slight clarification: if I am not wrong, a __Host cookie is still
>> not tied to origins. A __Host cookie on foo.bar.com will also go to
>> baz.foo.bar.com.
>>
>> --dev
>>
>>
>>
>> On 16 August 2018 at 19:17, Erik Nygren <erik@nygren.org> wrote:
>>
>>> I think my primary use-case is covered if we define a way to allow
>>> servers and/or origins to force Cookies to conform to the Origin model.
>>> (Being able to indicate that cookies are prohibited on an Origin is perhaps
>>> a secondary use-case.)
>>>
>>> Providing an ability to constrain cookies to the Origin model for a
>>> given Origin (and/or to prohibit them entirely) would help normalize some
>>> of the pain associated with cookies.
>>> Defining a simple header focused specifically on this use-case as part
>>> of 6265bis might be be one possible path, and that aligns with some of the
>>> other goals of 6265bis (eg, the introduction of __Host cookies).  For
>>> example, a response header of:
>>>
>>>     Limit-Cookies: origin
>>>     Limit-Cookies: none
>>>
>>> that would either be a sticky attribute to that origin and/or host
>>> (likely up to some expiry) or would apply to any active content resulting
>>> from the object associated with that response header.
>>>
>>> The challenge is that there's no way for a server to constrain all
>>> cookies to be __Host cookies (or otherwise be same-origin cookies) as
>>> javascript running within that origin context can choose to set cookies on
>>> something broader than the Origin.
>>>
>>>        Erik
>>>
>>>
>>>
>>> On Thu, Aug 16, 2018 at 9:37 PM, Devdatta Akhawe <dev.akhawe@gmail.com>
>>> wrote:
>>>
>>>> Hey Yoav
>>>>
>>>> Would __Host cookies help here? Maybe I am missing something about the
>>>> problem but it feels like they should.
>>>>
>>>> --Dev
>>>>
>>>> On 16 August 2018 at 01:41, Yoav Weiss <yoav@yoav.ws> wrote:
>>>>
>>>>> Hello folks!
>>>>>
>>>>> Akamai has ran into some issues with cookies where Cookie Controls
>>>>> <https://w3c.github.io/webappsec-csp/cookies/> would've been
>>>>> extremely helpful. Digging up the issues that lead to its obsoletion didn't
>>>>> reveal much reasoning, so I'm wondering why is was rendered obsolete, and
>>>>> whether there are alternative proposed mechanisms to replace it.
>>>>>
>>>>> Our use case is providing customers traffic delivery in
>>>>> customer-controlled subdomain of an Akamai domain. An example of that would
>>>>> be cdnexampledomain.com where foo.cdnexampledomain.com and
>>>>> bar.cdnexampledomain.com are customer-controlled.
>>>>> The concern is that each of these subdomains can set cookies on the
>>>>> cdnexampledomain.com domain, polluting the shared namespace, and
>>>>> sending cookies to domains outside their control.
>>>>>
>>>>> While Akamai can filter header based cookies on those domains, it
>>>>> cannot prevent JS from adding such cookies.
>>>>>
>>>>> We would be interested in a header that we can set, and which can
>>>>> prevent those subdomains from setting cookies on the parent domain, while
>>>>> enabling them to continue to set whatever cookies they need on the
>>>>> subdomain itself.
>>>>>
>>>>> When mentioning this use-case on the call yesterday, suborigins
>>>>> <https://w3c.github.io/webappsec-suborigins> was raised as a
>>>>> potential solution for this use-case, but looking at the draft, I'm not
>>>>> sure how it would without making those subdomain documents cookie-averse,
>>>>> and make it so they can't set cookies from JS at all (which may not be
>>>>> compatible with current, non-malicious content on those domains).
>>>>> But it's fairly possible that I'm Holding It Wrong™.
>>>>>
>>>>> I also realize that we want to move away from cookies
>>>>> <https://github.com/mikewest/http-state-tokens>, which would be
>>>>> great, but in the {short,mid}-term they'd probably still be around, so
>>>>> better control mechanisms can be very helpful.
>>>>>
>>>>> To sum up, my questions are:
>>>>> * Why was Cookie Controls obsoleted?
>>>>> * Are there any alternatives? Otherwise, can it be revived?
>>>>>
>>>>> Cheers :)
>>>>> Yoav
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>