Web Application Security Working Group Teleconference -- 09 Feb 2015

<trackbot> Date: 09 February 2015

<jww> zakim: jww is aaff

<jww> darn, I always forget the syntax.

ckersch and tanvi send regrets

<jww> bhill2: thanks :-)

<bhill2> scribenick: dveditz

<mkwst> jww, bhill2: http://www.w3.org/2015/07/zakim.html <-- the countdown

Minutes Approval

<bhill2> http://www.w3.org/2015/01/12-webappsec-minutes.html

bhill2: any objections to the minutes from last month?

Agenda Bashing

bhill2: hearing none minutes are approved by unanimous consent

<francois> can we add a quick topic to "go around the table" and check whether or not anybody wants to keep NI URIs in the SRI spec?

dwalp: can we swap CSP and MIX?

bhill2: any objections?..... ok, we can do that

Rechartering & Mozilla's formal objection

<francois> ah, sorry, missed it

bhill2: the ni:// topic is already on the agenda
... we've been working on rechartering for a while. at 11th hour we got an objection from Mozilla
... others have chimed in to support those concerns

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0066.html

bhill2: I have posted a diff

<bhill2> <- Moz's objections

<bhill2> https://w3c.github.io/webappsec/admin/webappsec-charter-2015.html

<bhill2> https://github.com/w3c/webappsec/commit/433dcc996c092309b88c4e1ecad425ea80a49aed

bhill2: we have room to figure out what those specs are going to look like
... [reads the diff of clarification around COWL spec]
... objection from mozilla was that they couldn't support it without further clarity.

deian: I made a comment on the change... looking for link

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0114.html

deian: dev brought up the thought we coiuld say @@ labels rather than origin labels but I don't know if he still thinks that

<deian> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0114.html

bhill2: here's a note from anne, not sure if it's an official mozilla response
... next objection was about EPR spec, breaking the ability of the web to link.
... [reads clarification diff for charter]
... one response on the list saying that may not be strong enough

<mkwst> dveditz: Sounds good to me, personally. EPR isn't terrible, real security benefits.

<mkwst> dveditz: similar to x-frame-options, who gets to control framing, etc.

<mkwst> dveditz: hope we can make a spec that satisfies folks in Mozilla.

<mkwst> dveditz: working on behalf of user to protect user.

thx mkwst

<mkwst> bhill2: Can you round-trip that back to Mozilla?

bhill2: next objection... unclear what the high-level wording about powerful features meant. removed from the summary but added the Powerful Features spec as an explicit deliverable
... the updated charter description says "The recommendation will include non-normative advice on when a feature might designate itself as requiring a secure context and provide a normative algorithm for determining if a given context is sufficiently secure"
... Mike, does that wording work?

mkwst: I believe there's a W3 group making a recommendation this week, it's important that someone has oversight on this area if not the WebAppSec WG

<deian> +1 I agree with mkwst

bhill2: I tend to agree with you, Mike, that rather than taking this out or moving it to the TAG calling it non-normative may allow us to make a strong recommendation that can be used by other WGs without dictating to them

mkwst: my concern is groups who don't consider security until it's too late. I hope we can stop that from happening

bhill2: if you can live with this language, Mike, and if Mozilla can live with it then I hope we can move forward with something the TAG can reference

mkwst: [didn't catch]

bhill2: so noted. we are presenting the technical recommendation we are just not making it mandatory

<bhill2> mkwst: notes that the recent TAG finding on securing the web explicitly delegated the technical bits to this group

bhill2: the last section was about asynchronous decision making, explicitly referencing the WebApps charter

<mkwst> bhill2: perhaps we can skip to MS's concerns around MIX? I think Dave(?) has ~5m left before his next call.

bhill2: that group doesn't have regular meetings so what we've been doing works well for us in ways that wouldn't for them
... [reads updated wording in charter]
... are there any further comments on the charter update or on the formal objection?
... I like to ask you, Dan, to take this back to the Mozilla folks and round trip this ASAP. the sooner we can have this resolved the sooner we can get on to the rest of the stuff we have to do

dveditz: I will do that

Strict mixed content checking (was Re: MIX: Exiting

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0148.html

bhill2: we have agreement from Tanvi from the Mozilla side to the late breaking changes, we were waiting for input from Microsoft

dwalp: no objections from MS

tanvi: none from Mozilla

mkwst: the only concern I'm aware of is from TBL posted to the list a few weeks back

bhill2: I asked him explicitly about that and have not received a response. Think we should call for consensus and take it to CR

<bhill2> ACTION bhill2 to issue CfC to take Mixed Content to CR

<trackbot> Created ACTION-212 - Issue cfc to take mixed content to cr [on Brad Hill - due 2015-02-16].

bhill2: congratulations Mike

IP matching (URI/IRI normalization) in CSP

bhill2: jumping back to CSP
... URI/IRI normalization threads, can we come to an agreement on how we support these sources?

mkwst: also wrt normalization bsmith raised whether we should support unicode in the context of the <meta> tags

<bhill2> raise ISSUE should CSP support unicode, at least within the context of meta tags

tanvi: wrt IP addresses have you, Mike, found out whether there are addresses used in practice?

mkwst: takes time to get data back, I've put in the request

tanvi: would be good to restrict to localhost only (for compat reasons) and not add others

bhill2: I think the proposal on the table is to remove IP address support from CSP spec but not necessarily rip it out immediately from implementations

terri: is there a way to make it an option for later? I'm afraid we'll hit IoT situations later where devices can't use CSP because they only have addresses

mkwst: moving from not supporting to adding it back in later is easier than vice versa

terri: agreed, but I don't want the language to imply "this is a terrible ideal that no one should use ever"

bhill2: I'm sure we'll want to allow 'self' to refer to the device even if it only has an address
... is there someone else they'd want to refer to?

terri: there may be associated devices that talk to each other, it's not unreasonable that one device would include data/graphs from another
... I don't know if any of them will ever use CSP, but we do have people working on things like that
... I don't know what the reason not to support IPv6 other than convenience

jww: I think it was more that we couldn't come up with a good syntax to support it yet, rather than the concept

bhill2: we don't want to hold up CSP2 while we try to come up with normalization rules for it

terri: that's fine, especially if we add a note that we're working on it for CSP 3

bhill2: do we want to commit now to a feature in a future spec?

terri: we don't have to commit, can we just say we think it's possible in the future?

bhill2: that's sort of committing. we're close to CR I'd like to avoid changes to the text

terri: I'm fine with it not being in CSP2 explicitly as long as we know it's in our heads

'self' in sandboxed contexts for CSP

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0084.html

jww: I'll file an issue on it

bhill2: concern was that in some cases sandboxed iframes CSPs with 'self' don't refer to anything reasonable
... diff of opinion about whether 'self' refers to the "effective script origin" or whether self should disappear if the document goes into the sandbox

jww: sandbox already breaks stuff if the content isn't aware of it

mkwst: sandbox breaks things like local storage, if the content isn't aware it's being sandboxed then it won't work

@@: that means you can only use CSP if you specify full origins, not 'self'

bhill2: also depends on when the sandbox is applied wrt CSP

mkwst: a good counter example from my point is frame-ancestor. it needs to know what the origin is before the sandbox is applied in order to specify it
... I would be hard pressed to write an exception to make this case easier to understand

jww: is it an intended consequence of a sanbox? we agree that scripts may not run, fine, that's why you sandbox. is this like that or is it surprising?

mkwst: I can see both sides. I can see it would be useful to be able to grab a real resource origin in some cases. what do we do with paths especially if they're set by pushstate?
... do those match a source expression? seems problematic
... I think there are more impt topics to attend to

jww: I think anne was on oyour side, too. I'm not sure we should be adding a 3rd origin type

CfC: Transition CSP2 to CR.

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Jan/0266.html

bhill2: I was on the side of not breaking but have been won over, Dan how about you?

dveditz: I will answer on the list, unable to scribe and think here. I may be won over
... is the unicode issue the only remaining issue?

deian: I think brian's point about nonces are too

<bhill2> https://lists.w3.org/Archives/Public/public-webappsec/2015Feb/0116.html

mkwst: brian had a couple of concerns. referrer directives, unicode, ..... [?] those are the 5 issues

bhill2: you already moved the referrer directive into the referrer spec right?

mkwst: yes

bhill2: the xss filter directive was moved to CSP3?

mkwst: I wasn't against it, haven't yet
... dev's suggestions for nonces ....

<mkwst> dev's suggestions are at https://lists.w3.org/Archives/Public/public-webappsec/2014Nov/0076.html

deian: maybe we could just note the potential for problematic uses of nonces

bhill2: nonces were never intended to be super secure, they were inteded to be more secure than not using CSP or using 'unsafe-inline'
... given we have two implementations already we would require a strong evidence of potential misuse to make a change at this point
... if brian is the only one with a strong objection to how nonces work and there are no formal objections, and strong support for moving CSP2 ahead I would like to make a call for consensus that nonces will work the way they work in the current implementations.

<bhill2> ACTION bhill2 to reply to brian smith re: CSP2 to CR

<trackbot> Created ACTION-213 - Reply to brian smith re: csp2 to cr [on Brad Hill - due 2015-02-16].

bhill2: I appreciate brian's attention to the spec and smart comments, but we'll have to leave some of this for the next version of CSP
... I apologize to the SRI folks we didn't get to their issues
... thanks everyone, talk in 2 weeks

have to run

<bhill2> I'll do the wrap up, thanks Dan

- DRAFT -

Web Application Security Working Group Teleconference

09 Feb 2015

Attendees

Contents