Web Application Security Working Group Teleconference -- 29 Jun 2015

<mkwst> Uh oh. No chair === confused Zakim.

<dveditz> we're supposed to be using something else now?

<mkwst> trackbot, prepare teleconf

<dveditz> webex?

<trackbot> Date: 29 June 2015

<JonathanKingston> I'm on via Skype, sorry I couldn't sort a better line for today.

<mkwst> I'm one of those, but no idea which one. :)

<mkwst> dveditz: Anything to add to the agenda?

<dveditz> scribenick: mkwst

<dveditz> http://www.w3.org/2011/webappsec/draft-minutes/2015-06-15-webappsec-minutes.html

Berlin F2F Update + Agenda Bashing

dveditz: July 13-14 at Mozilla.
... Will send out a link to where exactly we'll be heading. It's on a Wiki somewhere.

<francois> https://www.mozilla.org/en-US/contact/spaces/berlin/

dveditz: Defined set of topics for that?
... upgrade-insecure-requests, SRI, other specs related to HTTPS.

<wseltzer> +1 to HTTPS switch

dveditz: Switching to HTTPS.
... Anything to add to that? Will overlap with the TAG on the 14th.
... Some folks are concerned about breaking sites by migrating, etc.

mkwst: Good converation for the list over the next two weeks.

wseltzer: Any logistical things to do? Sign in in advance? Check in?

dveditz: I've never been there. francois probably hasn't either.

<wseltzer> https://wiki.mozilla.org/Berlin_Office

dveditz: Regular Mozilla badges don't work there. We're all on our own.

francois: I'll look into it. Think we just need to sign in and go.

dveditz: There's a sticky name badge. It's exciting.
... Other than that, probably nothing.
... Could be tight. Execs are visiting too.
... Might get bumped to a smaller room.

CSP Pinning

<dveditz> scribenick: dveditz

mkwst: there hasn't been a lot of change since the last discussion
... hasn't been something I've been actively working on lately

<wseltzer> https://w3c.github.io/webappsec/specs/csp-pinning/

mkwst: CSP pinning is a mechanism by which a site can declare a policy that should be applied to every page
... we discussed two possible ways -- a default policy that individual pages could tighten, but not remove
... the other option would be to set a policy that applies only if there are no policies from the page itself, such as for error pages
... the spec currently goes with the former -- policy is always applied -- but there are good arguments on both sides
... what makes sense to me is to have the default be a policy that applies if no page policy, with an option to make a blanket policy
... the other open question is the delivery mechanism
... the spec has one mechanism, there are two other ways... 1) would be a manifest, which fits with the concept of a web "application"
... but the manifest has a different scope than CSP (which would be origin-wide) and manifests can also be scoped to @@ which doesn't fit with an origin-wide setting
... a manifest can also sometimes define policy for other domains (if installed from that domain)
... 2) someone also suggested a file on disk (e.g. under /.well-known) similar to a manifest, but separate to avoid the above concerns
... biggest question is whether we can allow this to apply to more than just one domain -- such as HSTS's includeSubdomains feature
... but HSTS has a self-verification mechanism (if the site isn't tls it fails miserably)

wseltzer: I'm interested in thinking about the "include subdomains" bit... are there places it could go wrong? clearly there are
... yet it seems useful for sites using subdomains as an isolation mechanism

mkwst: the question is what extent we can treat subdomains as the same entity
... in the sense of having administrator control
... we're forced to to some extent due to cookies, but that's a bad reason

wseltzer: this is related to the work by dbound at IETF talking about the public suffix list
... at the highest level "is this a domain delegated by a registry or by a private entity?"
... if a university sets subdomains for all of its students how much control should the university have over them?

mkwst: I'd like to stay away from the PSL discussions as far as possible
... it's a complicated problem. there are areas it works well and areas it does not
... to take your last example the university has complete control over those machine (most likely) and if they don't they certainly have control over the dns

<JonathanKingston> Resold domains match this case, like .co.com domains are not normal domains for example

wseltzer: it would be interesting to describe some of these things in DNS -- same level of granularity-- but previous efforts along those lines have been unsuccessful

<wseltzer> https://tools.ietf.org/wg/dbound/

mkwst: that's about it, but I haven't worked on it lately and not the top of my priority list
... have taken feedback to heart and have focused on finishing other specs first
... if we need to update things for heartbeat requirements I can push an update

wseltzer: every 3 months is recommended

<wseltzer> http://www.w3.org/2014/Process-20140801/#three-month-rule

mkwst: ok, then I'll publish a new WD based on what's there right now, but otherwise I think other work in our queue is more important

<mkwst> scribenick:mkwst

<scribe> scribenick: mkwst

deian: Delayed with the COWL spec.

<dveditz> Confinement with Web Origin Labels (COWL)

deian: Getting close to something like a working draft.

Confinement with Web Origin Labels (COWL

deian: Not sure if folks have looked at it yet.

<deian> http://cowl.ws/spec.html

deian: Pushing it out now for discussion.
... To summarize:
... Want to extend the web model with labels.
... Confidentiality labels and integity labels.

<tanvi> did the call get cut off?

deian: Should associate a label whenever you share data (postMessage, etc).
... Compliments the existing model, share data, determine with whom it can be further shared.
... Labels and priviliges are main concepts.
... Once I read data, I'm tainted.
... based on labels.
... Privileges gives you ownership over your own origin, declassify/endorse data for this origin.
... Because conjunction/disjunction, can delegate privilege.
... In the current draft, have described the concepts and interfaces.
... Introduced a new primitive, labeled objects.
... Can send object over, policy is imposed at that point.
... Anything that's structurally clonable.
... Also a header mechanism.
... Extending XHR/Fetch to return labeled objects.
... Labels are enforced at context boundary. IFrames are a natural choice.

<JonathanKingston> Mike could you mute your mic please?

deian: Spec also introduces lightweight workers.

(JonathanKingston: Sorry!)

scribe: Can delegate privilege to the workers.
... Should that concept be part of the spec? Moved to v2?
... All specified now? Rip out bits for draft?

wseltzer: To advance a spec, you need two independent implementations of all the key features.
... If things will lag behind, then subsets make sense as a v1.
... Could be faster than labeling things as "at risk" and taking them out.
... Easier to wrap hands around a smaller spec.

mkwst: Ditto.

deian: Enforcement. Specified in terms of CSP?

<scribe> ... New directive into CSP.

mkwst: What do you mean by "enforcement"?

deian: We perform the checks ourselves.
... current context has a label, which could map to a CSP.
... Say you have "example.com". You can talk to "example.com", but no one else.
... Still need label checks in the spec, but when contexts talk to other contexts or to servers, that maps well to CSP.

mkwst: CSP only allows tightening.

deian: Would have to keep track of policy set by COWL vs header. But would want the union.

<wseltzer> mkwst: CSP is already pretty far out of date

<wseltzer> ... with respect to Fetch

<wseltzer> ... so CSP3 will be rewriting a lot

deian: Ok. Will look at fetch too.
... Will chat with mkwst later.

JonathanKingston: If I load Stripe on a website, how do I restrict Stripe to sending data to stripe.com, without restricting the parent page?
... Site shouldn't own the data the user typed in.

deian: Would help to have lightweight workers. Or an IFrame.
... Set the label of the frame to "stripe.com", it can only talk to stripe.com without restricting the parent.

JonathanKingston: I'd prefer the embedding site not to see what's put into the Stripe IFrame.

deian: Labeled objects: unless you inspect the data, it won't taint your context.
... Stripe could give you an object, you could hold onto it. It won't effect your ability to communicate until you look at the data.

JonathanKingston: Ok.

deian: will add that as a use case into the spec.

dveditz: Have you given thought to how sites could misuse this for evil?

deian: Yes.
... Navigation source === can't navigate away if you fully taint your context.
... Not too worried about misuse of the rest.
... Should be using this _in addition to_ everything else, though.
... Tempting to loosen CORS, for instance, but need to be careful about doing so.

dveditz: For navigations, maybe if user agents obey what a user says (address bar, bookmarklet, etc).
... Some sites will say "paste this!", so that's not a guarantee.

deian: Bookmarklets are injected into the page, so maybe they should be governed by COWL...
... Will further explain the guarantees this provides.
... Question for FPWD.
... How complete does it need to be?

wseltzer: Idea is to have a scaffolding that's enough to show people what's going to be there, and for the group to agree that it should go out as an FPWD.
... When you think it's ready, send a signal, we'll start the process moving.

deian: Great! Might be ready by the end of the week.

dveditz: Ok. That seems to have covered the two topics we had for this call.
... Close it up?

<wseltzer> mkwst: CfC on Mixed Content to Proposed Rec. Please send comments/feedback

wseltzer: Looking forward to talking at the F2F about all the good work we're doing here.
... Telling the broader story about the things we're doing to help secure the web.

dveditz: Thanks everyone.
... Next call would have been during the F2F. Maybe we'll have a call? Will check with Brad.
... May call in for folks. Might be an odd schedule for that.
... Will send out a mail.

<deian> wseltzer: thanks! :)

wseltzer: Will be bidding farewell to Zakim. Next time, new numbers anyhow.

dveditz: Is there a phone number for the new thing?

wseltzer: Yup. You can dial it from a telephone.

dveditz: See you in Berlin!

<dveditz> ok, thanks

<wseltzer> s/

<dveditz> I don't think I had two spaced in "be handled"

<dveditz> s/wseltzer: does RRSAgent go away at the same time? if so how is IRC logging going to be handled?//

<dveditz> :-) thanks

- DRAFT -

Web Application Security Working Group Teleconference

29 Jun 2015

Attendees

Contents

Berlin F2F Update + Agenda Bashing

CSP Pinning

Confinement with Web Origin Labels (COWL

Summary of Action Items

Scribe.perl diagnostic output