Re: CSP3 as a polylithic set of modules?

On Mon, Sep 28, 2015 at 11:15 PM, Brian Smith <brian@briansmith.org> wrote:
>
> Reporting should be specified, normatively, in Javascript code that uses
> the CSP2 DOM events and XHR to do what browser's reporting modules do. I
> don't think reporting is really "core" to CSP, even though it is a very
> useful feature. In particular, the reporting mechanism only makes sense for
> browser implementations of CSP, but it doesn't really make sense for
> server-side or client-side templating engines that take a CSP to guide them
> in rejecting bad inputs (input-side validation instead of output-side
> validation of CSP). So, I think reporting should be moved out of core.
>

I think we agree on the conclusion, but maybe not on the way to specify
things. In particular, there are a few other specifications with reporting
requirements (HPKP, NEL <http://www.w3.org/TR/network-error-logging/>,
etc). I've talked with Ilya a bit about extracting the reporting concepts
from each of these documents into one place that deals with things like
batching and retrying, which are difficult-to-impossible to do with
JavaScript alone.


>
>
>> As a test balloon for this last bit of the proposal, I've sketched out
>> mnot's `cookie-scope` idea as a separate document at
>> https://w3c.github.io/webappsec/specs/csp-cookies/. WDYT? On the one
>> hand, it's pretty small. On the other, perhaps browser vendors could be
>> encouraged to tick a number of tiny checkboxes faster than they might tick
>> a big checkbox, even if the functionality is the same?
>>
>
> The main advantage I see in splitting out features into multiple documents
> is that things that trigger the W3C process causing a document reverting
> back to CR from PR (etc.) would negatively affect smaller pieces.
>

And lighterweight documents can navigate the process more easily to begin
with.

Basically, I'm frustrated that it took ~3 years to get CSP2 out the door.
There was basically nothing in that document that should have taken so
long, and I think we would have made more progress more quickly if we would
have split the things that practically everyone agreed upon out from the
things that were more contentious.


> Since the goal seems to be to prioritize features that browsers should
> implement right away
>

That's one goal. Another is to break the spec up into logical chunks, so
that we're not updating the whole thing when changing things in one piece
or another. mnot's cookie proposal languished because I totally thought
CSP2 was done ~2 years ago; there's no reason for that other than my own
organizational shortsightedness.

Splitting stand-alone features out into stand-alone documents allows them
to proceed at a pace that's appropriate for the feature, rather than
blocking everything on whatever turns out to be slowest.


> 1. Features that everybody implements (approximately CSP 1).
>

This seems too broad: as you noted, there are distinct categories of
directive, and splitting them out into documents that describe that
category seems like the clearest way to go.

Really, we already have a CSP1 and CSP2 document. I'd like to avoid
producing anything that long again. :)

2. Aspects that affect compatibility with CSP-1-only implementations. For
> example, if there are aspects of the CSP 2 syntax that cause CSP-1-only
> implementations to fail to parse the policy, because the policy conforms to
> CSP 2 syntax but not CSP 1 syntax, then these issues should be addressed in
> some way.
>

In the model I have in mind, this would require changes to "core".


> 3. Apsects of CSP that are really important for a browser to implement,
> because they cannot be enforced by input-side validation of CSP policy
> conformance (on the server or in JS code implementing a templating engine).
> For example, "frame-ancestor" is very important for browsers to implement
> because it can't be enforced input-side, but new source-list stuff is less
> important because the templating engine can and should have already have
> prevented all that badness in the first place before the browser sees it.
>

Agreed.


> 4. The defense-in-depth features that are redundant with good input-side
> validation practices but which are critical if you have a bunch of terrible
> code sitting on your servers with bugs that you want to use CSP to
> wallpaper over.
>

This is most of CSP in your model, right?


> Ultimately, I think it is unreasonable to expect web browsers to invest
> time to implement features that just wallpaper over server-side bugs, and I
> think a lot of CSP would actually be classified that way.
>

I guess I disagree (folks aren't using the templating solutions that exist,
and when they do, they do so poorly), but I also don't think that
disagreement has much to do with the structure of the document we produce
at the end of the day.


> I think CSP is brilliant but I think our emphasis on browser enforcement
> of CSP policies is counterproductive in the long run. Most of CSP should
> actually be enforced by the templating engines. I think the idea of sending
> a CSP header with a bunch of source-list directives for the browser to
> enforce will be considered an obsolete practice in a few years as
> input-side enforcement of CSP gets implemented and deployed.
>

1. I would love CSP to be obsolete in a few years.
2. "in a few years" is a few years away.

-mike