Re: [webappsec] POLL: Getting CSP 1.1 to LCWD

On Thu, Oct 3, 2013 at 9:43 PM, Carson, Cory <Cory.Carson@boeing.com> wrote:

>  I agree that CSP should say nothing about addons, with the following
> caveat. When the issue was originally raised about CSP implementations
> affecting addons, CSP was intended to not affect contents’ TCB but it was
> not immediately clear how to express that in a theoretically pure manner.
> The reference to addons was added as a practical matter, and while
> theoretically impure, it was close enough to convey the goal of CSP. Until
> now. Should a theoretically pure yet practical way to spec this goal for
> CSP appear, it should supplant the statement about addons entirely.****
>
> ** **
>
> I did not properly convey the full meaning of my usage of ‘restricting the
> user agent’, based on your citing of Section 3.3. Section 3.3 discusses an
> entirely different nature of restriction than the one I meant. Please allow
> me to rearticulate.****
>
> ** **
>
> The CSP spec restricts the user agent in such a way to enable content to
> be self-limiting; that is, enable the content to instruct the user agent to
> restrict the content itself. With CSP, contents’ restrictions are
> self-inflicted. This is intended to allow content authors to protect users
> against exploits of any flaws that reside in the content itself. The prime
> example of a reason to do this is content authors practicing defense in
> depth. The user agent’s TCB does not affect the needs of CSP, and so CSP
> restrictions stop there. Implementing CSP requires neither DRM, nor
> hardware root of trust, nor malware protection (antivirus). The act of
> spec’ing CSP requires neither participants versed in DRM, nor regional
> regulatory participation, nor malware protection (antivirus) vendor
> participation.****
>
> ** **
>
> Item 6 restricts the user agent in such a way to enable content to limit
> the contents’ TCB; that is, enable the content to instruct the user agent
> to restrict the user agent itself. With item 6, contents’ restrictions are
> inflicted upon the user agent. This is intended to allow content authors to
> protect content against users. Your given examples of reasons for doing
> this include legal restrictions (emergency alert), contract enforcement
> (subscription terms), or poor user choices (naive users installing malware
> or malicious addons). Because the user agent’s TCB violates such a spec (eg
> user agent addon hiding the fact that the content requested the user agent
> to restrict the user agent), the restriction applies to the user agent’s
> TCB. In fact, it applies recursively to each layer of the content’s TCB,
> all the way down to hardware. Implementing item 6 requires DRM, hardware
> root of trust, malware protection (antivirus), or all three. The act of
> spec’ing item 6 requires participants versed in DRM, regional regulatory
> participation, and malware protection (antivirus) vendor participation.**
>
> ** **
>
> Despite both CSP and item 6 restricting user agents, the nature of the
> restrictions are very different. The concerns of implementing them,
> spec’ing them, are very different. I argue that the concerns are in fact
> different enough that CSP and item 6 must not co-exist on the same
> deliverable (document).****
>
> ** **
>
> Expanding upon my proposal of discussing item 6 as a hypothetical new
> document, a title of “User Agent Security Policy” may work. The title alone
> may help convey the difference between this and CSP: “Content Security
> Policy” restricts content, “User Agent Security Policy” restricts user
> agents.****
>
> ** **
>
> Additionally, this hypothetical document may serve as a home for other
> similar client integrity requests, such as PayGate’s request for
> standardized antivirus/antimalware attestation. In fact, you may wish to
> ask PayGate if they will assist you in drafting such a document.****
>
> ** **
>
> Ultimately, such a document needs to have a home. I encourage you to pitch
> your proposals as this hypothetical new document to this working group.
> That said, the WebAppSec Chair has already stated earlier in this thread
> that the topic is beyond the charter of this working group; you likely will
> need to find a different area within the W3C to pick this up.
>

Thanks for your clarifications. While I now agree that addressing this
issue is better aligned with the notion of constructing a "User Agent
Security Policy" (or equivalent) document, I am still not willing to grant
either:

(1) that an add-on is necessarily part of a UA's TCB;

or

(2) that a request by a content author to restrict the use of add-ons is in
any way related to the conventional goals or definition of DRM; for
example, the restrictions I am suggesting here are intended to be
potentially applicable to any type of content (i.e., may be requested by
content resourced) whether subject to copy protection or not and whether
subject to any other restriction on content access, content copying,
content use, etc.; using the term DRM to describe what I'm suggesting seems
very strange to my thinking;

In conclusion, I would be satisfied if the current language I've cited in
CSP (both 1 and 1.1) is simply removed, leaving this a matter of UA vendor
interpretation, until a more in-depth treatment can be afforded.


> ****
>
> ** **
>
> ----****
>
> ** **
>
> On Tue, Oct 1, 2013 at 3:36 PM, Glenn Adams <glenn@skynav.com> wrote:****
>
> ** **
>
> On Tue, Oct 1, 2013 at 3:02 PM, Carson, Cory <Cory.Carson@boeing.com>
> wrote:****
>
> I respectfully maintain the position that item 6 is out of scope for CSP.
> I recognize that your proposals bring legal, user safety, or PoC benefits
> for some actors in some situations, and I maintain my position that the
> discussion be framed in the context of a hypothetical new document added to
> the working group's scope.****
>
> ** **
>
> If CSP said nothing about add-ons, then it would be better than what is
> there now. What is *in* CSP now:****
>
> ** **
>
> "Enforcing a CSP policy *should not* interfere with the operation of
> user-supplied scripts such as third-party user-agent add-ons and JavaScript
> bookmarklets."****
>
> ** **
>
> Brings the subject of add-on behavior in scope by itself. Suggesting that
> a hypothetical new document take up these processing semantics in more
> depth seems a very strange suggestion.****
>
> ** **
>
> Considering your suggestion (of a new document) a bit more, I could accept
> that approach if the above language was struck from both CSP 1.0 and 1.1,
> and this new hypothetical document took up the matter of normatively
> defining behavior surrounding add-ons/extensions, including the possibility
> of defining new directives used in this context.****
>
> ** **
>
> --snip---****
>
> ** **
>
> Pardon me, but Section 3.3 Processing Model [1] says:****
>
> ** **
>
> "To enforce a CSP policy, the user agent *must* parse the policy<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#parse-a-csp-policy> and
> enforce each of the directives contained in the policy, where the specific
> requirements for enforcing each directive are defined separately for each
> directive (See Directives<https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#sec-directives>,
> below)."****
>
> ** **
>
> If this isn't a restriction on the user agent, then I don't know what is.
> Any normative statement of what a user agent "must" do is a restriction on
> the user agent.****
>
> ** **
>
> [1]
> https://dvcs.w3.org/hg/content-security-policy/raw-file/tip/csp-specification.dev.html#processing-model
> ****
>
> ** **
>