SV_MEETING_TITLE -- 02 May 2012

<bhill2> hmm, looks like we may not have a reservation anyway

<gioma1> bhill2: does it mean the bridge is not available?

<bhill2> let me try again

<bhill2> zakim this is 92794

<bhill2> sorry folks, looks like the staff didn't get the reservation set up in time

<bhill2> bridge is unavailable

<bhill2> getting a slow start today, waiting for folks to arrive in person

<bhill2> I have put in a request for the phone bridge for tomorrow, Philippe is following up. Possibility of getting it enabled later today.

<bhill2> phone bridge should be available within the 1/2 hour

<scribe> scribenick: ekr

bhill2: start installing your vms

<bhill2> bridge is up

<bhill2> zakim aaaa is bhill2

<bhill2> who just joined?

<bhill2> sorry to yank the rug, but we are headed next door to webapps to discuss last call comments for CORS

<bhill2> will be back at 10:15, and I will leave the bridge open

jeffh: the current spec is baffling if you're not a browser implementor
... I told Anne that already

<plh> oops

[discussion about how to pass this information back.]

Scribing will be happening in webapps for now

<gopal> which room are you meeting in

<dveditz> gopal: the one with all the people in it

<dveditz> (didn't catch the name on the way in)

<gopal> what happened to saturn

<dveditz> --not-- the one with the sign outside saying webapp security

<gopal> ok

<dveditz> talking about CORS

<dveditz> joint with webapps, guess we're in their room for that

<gopal> will be there

<bhill2> ACTION to bhill2 to integrate jeffh comments into sec considerations in CORS

<trackbot> Sorry, couldn't find user - to

<bhill2> ACTIN bhill2 to integrate jeffh comments int sec considerations in CORS

<bhill2> ACTION bhill2 to integrate jeffh comments int sec considerations in CORS

<trackbot> Created ACTION-58 - Integrate jeffh comments int sec considerations in CORS [on Brad Hill - due 2012-05-09].

<jrossi> It seems the conference bridge's audio has stopped.

<abarth> jrossi: we had problems with feedback

<jrossi> Ah, I see. I'm fine with just watching the IRC if you guys take good notes. :-)

<dveditz> can you hear now?

we can hear you

<dveditz> I think we hear you

next agenda item: CSP 1.0 outstanding issues

<bhill2> can you still hear us?

<jrossi> cuts out most of the time, just bits and pieces

<dveditz> we all came to microsoft's campus, where are you? ;-)

<jrossi> haha, wrong campus!

<abarth> http://www.w3.org/2011/webappsec/track/issues/open

<dveditz> jrossi: most of us are far from the mic, we'll try to get closer when we say something substantive

<dveditz> right now there's lots of mumbling

<jrossi> that's probably it, I think noise cancellation is just kicking in since you're far away

abarth: I thought we resolved issue 8 a while ago

<dveditz> if *you* have noise cancellation you might try turning it off if you have a headset

issue 35:

<dveditz> that way your own noise won't cut our softer sounds off

<jrossi> i'm muted

dveditz: A lot of proxies will mangle this anyway

bhill2: this came out of IETF

dveditz: mozilla's solution was to have an intersecting policy
... I don't think we can say don't combine this

abarth: if there is a comma, there is an error processing case.

dveditz: the proxies will just merge them anyway.

abarth: how shall we handle the error of the server sending multiple errors and the proxy combining them.

dveditz: I can see how this happens.

[... discussion...]

Abarth and Dveditz suggest that comma be illegal.

abarth: how shall we handle it?

dveditz: I would prefer an intersecting policy

ekr: why not treat it as an ilelgal policy?

abarth: what should be the behavior if you get a policy without any of the known directives?

dveditz: shouldn't that be default source = none

tanvi/dveditz: why not take the most restrictive?

abarth: it's not clear which one it is?
... and now you're into intersecting policies

bhill2: this text I sent is designed to cover this.

abarth: turns out that comma is forbidden but we recover
... I suggest that with comma we set the policy to some invalid policy.

bhill2: like default src = none

abarth: yeah, and I would probably log in the error console.

ekr: how should we handle other cases where the policy is invalid,

abarth: e.g., directive name == backspace or dollar sign
... currently it gets parsed as a directive name. It's illegal but causes no failure.

ekr: the general philosophy is that if you can make sense of it, do it?

abarth: it's semicolon delimited, so if I don't understand the thing in between the semicolons, then I ignore it.

ekr: Do we want to revisit the design decisions (a) no intersection and (b) non-restrictive default policies.

dveditz: I wasn't paying that much attention before, but I would still prefer intersection

bhill2: the argument last time was that intersection was hard

dveditz: yah, it's not perfect. It does tend towards breaking the page.

bhill2: what about combining only policies of type src list

abarth: most important thing is for it to be extensible.
... want to have something good I can take back to websec
... can't merge on a directive by directive basis
... I see policy combination as really complicated and benefit is not that large

dveditz: what is the proposed handling if we get a comma?

abarth: the thought is that since it is syntactically invalid, the policy is now default source none and print something to the debug console.

dveditz: seems like ignoring everything after the comma is consistent with first policy wins, but maybe we don't know which order the proxies assemble the headers in

ekr: right, but this means that a bad policy is ultra-dangerous as opposed to breaking everything

bhill2: philosophy has always been that this is a safety belt

abarth: we find that when people deploy CSP, they find that there aren't a lot of violations and so they aren't sure policy is running.
... I would like to have some way to ask it.

bhill2: what if there is some proxy elsewhere.

ekr: what if there are multiple proxies? This makes it very dangerous...

abarth: do proxies like this really exist?

tanvi: so if we have two headers right now we do nothing?
... the other thing about intersecting policies is if we have meta tag and policy URI we might have to deal with this.

abarth: meta tag used to be trumped by header
... something else I want to talk about for 1.1--there is a use case to modify policy at run time. It's delicate to do that in a good way

bhill2: how he handle combination logic, then this impacts how things behave in the future
... in the future, we are going to have proxies which do CSP injection, then this won't work with any future meta tag

abarth: maybe say you must only send one policy and then if you receive two you fail in some obnoxious way.

and if we add a new way to get policies we specify a combination mechanism then.

bhill2: this still leaves it open how people who do want to do policy injection. We should give them some advice.

abarth: those people are more able to adapt.

bhill2: well, WAFs don't adapt much

ekr: well, the reason we didn't do it was because it was hard. If these guys want to try it, then good for them, but we don't have to

abarth: my current proposal {two policies, comma in header} --> enforce default src=none

bhilll2: so no meta tag?
... it's on the agenda later

bhill2: is now a good time to discuss the meta tag for 1.0?

abarth: I think we should talk about that in 1.1
... it's related to other things in 1.1

bhill2: the question of meta in 1.0 has to be on our agenda. shall we revisit it now because it may impact the combination logic.

dveditz: how so?
... other headers with meta tags have had the header override the meta tag

tanvi: what if we forbid duplication now and then specify merging in 1.1?

travis: historically don't meta tags trump headers

dveditz: tuypically the other way around

travis: from a security perspective, that seems ok, but practiclaly don't you want the opposite

abarth: that's just the way the web is even if it's backwards

travis: well, in some cases IE does that

dveditz: it's a matter of who wants what -- web pae authors versus site operators

travis: personally I want to not see meta tags in 1.0 so we finish

<abarth> http://www.w3.org/2011/webappsec/track/issues/open

taking a break till 11:30

<tanvi1> http://www.w3.org/TR/CSP/

we are back

topic is ISSUE #8

balance between the user's preferences and the site authors

dveditz: both user and site operator are concerned about attacks and the user can always override the site's preferences as a technical matter

abarth: my sense is that we agree about principles, and the details are a matter of the implementations which vary anyway

dveditz: if the UA lets the user add extensions, we are still respecting CSP in a reasonable way.

abarth: I view the current text as sort of aspirational.
... as an example, in Chrome a content script can load images from its own extension package regardless of CSP

ekr: I propose we mark this closed and move onto meta and sandbox

bhill2: we have requests from a bunch of people to restore the meta tag
... my summary is that there are a lot of site admins who can't set headers but would like to use CSP
... so this is worth the risk

abarth: my sense is that this interacts with CSP 1.1 proposed features such as the ability to query policy

dveditz: I'm much more concerned with a DOM API to set policy than I am about a meta tag

abarth: is there anyone who thinks this should be in 1.0?

tanvi: we'll need to discuss anyway

dveditz: one concern about injectable policy via meta is leak via reporting. maybe add same origin requirement for reports in meta
... would also like to restrict meta to HEAD

abarth: how would you feel if we restricted meta tag to HEAD. How would you feel if someone injected it later?

dveditz: I think that's cheating

abarth: so only if it's in head and available at the start.
... example is gmail

dveditz: what if I had a meta tag that said "allow deferred DOM API CSP injection later"

bhill: use cases is restrictive server environments
... maybe these use cases can't meaningfully consume reports anyway

dveditz: might be willing to stick to simplest use cases

tanvi: what would requirements be: meta tag == no report, meta tag must be in HEAD, must be no header

abarth: + must be inserted by parser

[discussion about what 'inserted by parser']

[discussion about what we are trying to achieve by restricting this?]

bhill2: if you can inject script then it's game over
... I'm not sure there is any reason to restrict it from being added by script

dveditz: the spec should just recommend that it go early.

bhill2: if you screw up before the meta, you're on your own

dveditz: want same origin reports

tanvi: don't want same origin reports--encourage people to use header instead of meta tag

bhill2: if you're only able to run static comment anyway
... how many scenarios is this relevant for?

tanvi: the only places this is really going to happen are corp environments and those people should go talk to their admins

abarth: my notes say

<abarth> Bringing back the <meta> tag,

<abarth> Header trumps <meta> tag

<abarth> First <meta> tags wins

<abarth> report-uri doesn’t work

<abarth> Guidance that delaying the header isn’t wise

dveditz: meta must come through parser.

bhill2: what's the security benefit here? All you can do is inject a new policy?

abarth: my preference is to not care how the data is inserted.
... suggestion is to use no insertion after ready state.

<gioma1> Zakim: ??P2 is gioma1

ekr: what's the security reason for this?

bhill2: It seems like an implementation simplification

ekr: ok

should we have meta in 1.0 or not?

nobody in room wants it in 1.0. people on list have requested ti

dveditz: we are probably closer to meta than sandboz

bhill2: if all implementors agree they don't want to do meta in 1.0
... then it doesn't need to be in 1.0 spec. by comparison, sandbox has some implementation. but no implementations, then meta loses...

tanvi: just because it's not in 1.0 doesn't mean people don't do it

abarth: my plan is to ahve it with a prefix

resolved: meta will be in 1.1 due to lack of implementor support for having it in 1.0. we will attempt to specify it early in 1.1.

<tanvi> what happened with onload vs inserted by the parser. i believe we decided the policy should be set onload? or did we decide not to specify that

bhill2: anyone want to revisit consensus on sandbox. We had interest from implementors on doing it, and we're going to re-check implementation status at CR...?

<dveditz> abarth was going to use wording along the lines of "before document readystate"

<tanvi> does microsoft have the full csp 1.0 implemented?

abarth: can we have a feature that we may drop if we do not have two implementations?

philippe: you need to mark it as "at risk"
... if you mark it as at risk, you don't need to recycle to LCWD if you drop it.

proposed resolution: we mark this at risk and then if we don't have two implementations, it gets dropped.

bhill2: can MS live with having this in 1.1?

travis: main concern is that it not just look like a MS feature

bhill2: jacob is willing to specify this

abarth: we outsource parsing to HTML5

dveditz: what if HTML5 changes?

abarth: they need to retain backcompat

bhill2: propose that we punt this to 1.1 since MS won't have a complete implementation anyway. Then we can move to LC soon.
... will raise on list

<scribe> ACTION: abarth to create 1.1 impl by end of week [recorded in http://www.w3.org/2012/05/02-webappsec-minutes.html#action01]

<trackbot> Created ACTION-59 - Create 1.1 impl by end of week [on Adam Barth - due 2012-05-09].

resolved: we will punt Sandbox to 1.1 pending approval on list.

dveditz: what about future compatibility for more specific policies, e.g., src lists that specify directories
... if we come up with a compatible syntax now.

abarth: proposal, allow full URLs but truncate to the origin.

<abarth> script-src http://example.com http://foo.com/bar/qux

<bhill2> dveditz: if someone types in https://www.google.com/ that is ignored because of trailing slash

<tanvi> script-src 'self' http://dev1.addons.phx1.mozilla.com https://addons-dev-cdn.allizom.org/

<tanvi> proposal: allow urls, and truncate them to the origin.

<tanvi> this ends up whitelisting an entire origin, when perhaps you just want to whitelist a path.

<tanvi> so perhaps we shoudl version cps?

<tanvi> *csp?

<tanvi> script-src and scipt-src-path

<tanvi> we could add a version to the specified policy. if the version =1.1, then allow paths in sources. if the version is 1.0, then ignore sources with paths.

<dveditz> choices appear to be a) version CSP header, b) duplicate directives in the future, c) degredation of hosts with paths

<dveditz> a) means two headers always. CSP2 clients need to look for both headers, sites may just leave CSP1 clients insecure

<dveditz> b) pretty much the same on a directive level -- either duplicate, or leave CSP1.0 clients as insecure as non-CSP clients

<scribe> ACTION: dveditz to write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [recorded in http://www.w3.org/2012/05/02-webappsec-minutes.html#action02]

<trackbot> Created ACTION-60 - Write a message to the mailing list describing his proposal for how to handle URLs with paths (truncate to the origin) [on Daniel Veditz - due 2012-05-09].

dveditz: people also want to be able to specify plugins by media type. E.g,, flash but no java

<scribe> ACTION: abarth to merge bhill's policy combination text into the CSP document [recorded in http://www.w3.org/2012/05/02-webappsec-minutes.html#action03]

<trackbot> Created ACTION-61 - Merge bhill's policy combination text into the CSP document [on Adam Barth - due 2012-05-09].

<abarth> http://www.w3.org/Security/wiki/Content_Security_Policy

<abarth> https://mikewest.org/2012/05/content-security-policy-feature-detection

<gioma1> are you people talking about clickjacking? I heard "...ckjacking" but it's all silence and some word here and here on the SIP bridge :(

<bhill2> talking about CSP 1.1 propsed features right now

<bhill2> I will try to turn up the microphone

<tanvi> i believe the anti-clickjacking discussion is tomorrow

http://lists.w3.org/Archives/Public/public-webappsec/2011Dec/0016.html

CSP access API?

http://www.w3.org/Security/wiki/Content_Security_Policy#Proposals_for_Version_1.1

peleus: what happens if you try to eval() with SCP

CSP

abarth: throw a security exception
... why is this useful? Avoid reporting errors for feature tests

frame-ancestor or frame-options

abarth: maybe we can get this back in

jeffh: now is a good time to participate in websec

abarth: maybe it should be possible for IETF documents to specify CSP directives

<tanvi> i have a couple of potential additions i'd like to bring up

bhill2: two ways to look at the world. (1). Anything new is CSP 1.1. (2) anything that changes how things work is CSP 1.1 and anything else is just new directives

tanvi: you have access to the wiki?

I just added some stuff

<tanvi> sure, i'll do that

<tanvi> added

script-hash

peleus: this seem like it's a maintainability issue

dveditz: this starts to get pretty long
... what about policy-uri?

<tanvi> this way you could imbed third party script that you trust (ex: facebook like widget) and know that if facebooks servers gets compromised, the hash won't match and your page won't be vulnerable

<tanvi> (regarding script-hash)

<tanvi1> script-src http://google-analytics.com [###]. so only http://www.google-analytics.com/ga.jsworks, and nothing else from google-analytics works.

no-user-js

tanvi: idea to prevent against self-xss.

no longer allow js: in address bar

but you could still get people to do "open"

idea would be to require special to activate the web console in these cases (where policy is provided)

dveditz: not sure how serious this is.... it is for fb and twitter

really only applies to a subset of sites.

ekr: this is a social engineering question

dveditz: interesting idea but not sure I want to jump right in on it.

next topic: restrict script to sources with specific content types

peleus: this causes a lot of problems

tanvi: idea here is to restrict scripts to a specific set of content-types

abarth: historically, this has been something people have ignored, so there will be a lot of collateral damage
... having it be opt-in

ekr: you could have the white-list in the directive

abarth: etter to ahve it be binary

form-action

bhill2: HTML5 makes form tag injection easier

abarth: this seems like it would help defend agains that and be within the scope of the kind of stuff we have done

plugin-types

dveditz: syntax seems complicated
... argue about it later

abarth: seamless with parent
... iframe can resized like a div.
... right now it's single origin
... might be nice to have a directive that allows it even without same origin

ekr: this seems like it's conceptually new since it's not a restriction

travis: IE already allows iframe resizing

abarth: this is a little different
... put it here so the group is aware of it. not sure where it goes

jsonp with padding

bhill2: a lot of people want to have safe JSONP
... jsonp-src : a list of domains
... jsonp-sink: a list of safe function names
... idea is that you could apply it to existing legacy code
... two objections from lcamtuf: (1) this doesn't solve jsonp being interpreted as scripts (2) it may not actually permit a lot of valid jsonp

ekr: this seems like a good idea, but not sure it can be made to work

abarth: I had one more... meta-referrer

finally, more granular origin list

tanvi: who has implemented meta tag for referer?

dveditz: should this be a meta tag? separate or in csp?

abarth: this feels like a policy thing

dveditz: I agree with that for things that are specified as headers....

bhill: distinction between proposals that rev the spec and proposals that add new directives
... what are examples of reving the spec? policy-uri, more granular origins

abarth is currently modifying the page to divide between experimental and proposals for 1.1

abarth: excited about form action
... plugin types might be a good one

bhill2: negative plugin tyes?

- DRAFT -

SV_MEETING_TITLE

02 May 2012

Attendees

Contents