Re: Cookie controls?

Two considerations I see:

1. Adding domains to the public suffix list is operationally scary as
there's no way to introduce a domain slowly and/or roll things back if
something goes wrong.  For domains with many thousands of heterogeneous
production use-cases, adding an existing domain is likely to be
unacceptably risky in some circumstances.
2. The PSL doesn't scale all that well, is an oddly centralized thing, and
feels like a hack.  This is less pragmatic, but it would be better if we
had mechanisms to allow getting to safer defaults for cookies without
relying on the PSL.

Best, Erik



On Fri, Aug 17, 2018 at 5:43 PM Artur Janc <aaj@google.com> wrote:

> 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
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>
>>>>
>>>