Re: Call for Consensus: Stop work and transition 3 Working Drafts to Working Group Notes

FWIW, I don't think same site cookies substantially diminish the value prop
of EPR.

1)  Same-site cookies don't prevent XSS.  To be clear, I'm not suggesting
that same-site cookies _should_ mitigate XSS, I'm just pointing to value
that EPR provides over and above same-site cookies.  For example, an
attacker might use an XSS in a page that doesn't require auth, then
subsequently attempt a same-site POST to an endpoint that does.  EPR is
valuable defense-in-depth given that other XSS mitigations (namely CSP)
approach this problem space differently.  CSP attempts to regulate what the
page can do whereas EPR attempts to provide a level of isolation.

2)  In order to mitigate XSRF with same site cookies it may be necessary to
opt-in to "strict" mode, which has some drawbacks.  (E.g.: It may require
separate "read" and "write" cookies to avoid compat issues, as per section
5.2 of the Same-site cookie draft RFC.)

In any case, EPR has been stalled for other reasons and I'm not going to
contest the proposed transition.  I just hope that it won't be too hard to
revive it as necessary in the future.

Dave

On Tue, Jul 12, 2016 at 2:33 PM, Brad Hill <hillbrad@gmail.com> wrote:

> This is a call for consensus to transition three Working Drafts of the Web
> Application Security WG to "Working Group Note" status and indicate that
> they are no longer under active development towards the Recommendation
> Track, as discussed at the May F2F and briefly on the list.
>
> The following specifications are proposed for transition:
> ---------------------------------------------------
> Entry Point Regulation
> https://www.w3.org/TR/epr/
>
> Last updated ~1 year ago.
> Reason to transition to Note: Same-site cookies (
> https://tools.ietf.org/html/draft-ietf-httpbis-cookie-same-site-00)
> provide much of the intended attack surface reduction more simply
> ---------------------------------------------------
>
>
> ---------------------------------------------------
> CSP Cookie Controls
> https://www.w3.org/TR/csp-cookies/
>
> Last updated ~6 months ago.
> Reason to transition to Note: The Feature Policy proposal (
> https://wicg.github.io/feature-policy/) could be a better home for the
> intended functionality as part of a broader and more coherent approach,
> rather than putting this into CSP.
> ---------------------------------------------------
>
> ---------------------------------------------------
> CSP Pinning
> https://www.w3.org/TR/csp-pinning/
>
> Last updated ~6 months ago.
> Reason to transition to Note: While this kind of feature is still
> considered useful, like Cookie Controls and Feature Policy, the editor
> feels it would be better managed as part of a more generalized strategy for
> header pinning, and as part of that, with a strategy perhaps along the
> lines of a manifest, well-known resource or service worker that doesn't
> incur the cost of sending the pinning header with every request.
> ---------------------------------------------------
>
> This CfC will be discussed on tomorrow's regularly scheduled working group
> teleconference (agenda to follow shortly on this list) and will close on
> Friday, 22-July-2016.
>
> Positive responses encouraged, silence is consent.
>
> Thank you,
>
> Brad Hill
>
>