Web Application Security Working Group Teleconference

13 Jan 2016

See also: IRC log


mkwst, francois, bhill2, dveditz, jww, terri, ckerschb, eisinger, freddyb, tanvi, wseltzer


<bhill2> thanks for setting up the meeting, wseltzer

<jochen> can we do referrer policy first please?

<bhill2> sure

<jochen> thx

Agenda bashing

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

bhill2: Any suggestions for agenda items?

mkwst: If we have time, we could chat about intranet/internet thing.

bhill2: Ok.

Minutes approval

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

bhill2: Objections to approving the minutes?

Documents for next teleconference.

All: <crickets>

bhill2: Approved!

Outstanding Calls for Consensus and Comments

<bhill2> SRI to Proposed Rec

bhill2: Topics for next time? Maybe the CORS thing if we don't have time today.

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

bhill2: SRI to PR?
... Objections to moving ahead?

all: <crickets>

bhill2: Huzzah. Approved, I'll send the transition request.

<bhill2> Mixed Content to Proposed Rec

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

bhill2: Might have been a bit premature.
... Only one implementation of `block-all-mixed-content`.
... Is it worth bothering to do that and `upgrade-insecure-requests`?
... Will produce less breakage.
... Hours away from turning on `block-all-mixed-content` for FB employees because I want to surface breakage early.
... Upgrade might hide that kind of breakage. I don't want to hide it.
... That's a development scenario, not a production scenario.
... Might not be worth implementing.
... It seems like it's the future, though, so maybe it's nice to let folks opt into that world.
... Mozilla folks?

tanvi: I brought this up.
... The FB scenario isn't something we've thought about.
... Other than that, I don't see the use cases.

<bhill2> mkwst: there are projects inside google planning to turn this on as a "strict mode", want to make sure they don't have http content

<bhill2> ... appealing to have strict vs. a transient upgrade mode

<bhill2> ... understand notion they are similar in nature, one is like a subset of the other

<bhill2> ... not everyone may see different use cases

tanvi: Couldn't you do this with CSP?

<bhill2> mkwst: doesn't cascade into frames

tanvi: Dan?

dveditz: I thought we had implemented it. :)
... I don't see why we wouldn't, but I don't feel strongly about it.

tanvi: I'll take this back to the team, and report back.
... In the meantime, what do we do about CR/PR?

bhill2: Feature at risk without 2 implementations, I'll object to my own CfC.
... We'll wait. Waiting is fun. We like waiting.
... I would rather hear "No" from Mozilla so we can start the process of removing it, as there's some exciting IPR process there.
... "Probably" is a particularly bad answer.
... Certainty would be nice.

mkwst: Reporting requirements? Currently none. Might be useful enough to be a requirement.

bhill2: Would be great to have. Probably not essential for PR. I'd settle for things breaking.

tanvi: Cascade makes reporting interesting.

<bhill2> tanvi: one issue is when it cascades into frames - be reporting on foreign content

<bhill2> dveditz: can treat it like we do redirects

<bhill2> CSP3 to FPWD

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

<bhill2> UI Security - new major editors' draft

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

bhill2: Expires Friday. Might be a good time to read CSP3.
... Would like feedback on UI Security before issuing a CfC to FPWD.
... Please read, and tell the group about it.
... Let's move Referrer Policy up.

Referrer Policy

<teddink> Apologies for my tardiness - dialing in now.

jochen: Quick update. We hammered out `referrerpolicy` attribute on <a> and <img>.
... Need to update published draft.
... We're missing spec tests for that feature.
... Requests for other elements as well. <link> for instance.
... Referrer policy delivered via CSP. Ran into some issues with things like redirects.
... Now looking into a dedicated `Referrer-Policy` header which has clearly defined behavior in cases like this.

dveditz: Do you mean that redirects could change the policy as you redirect?

jochen: Consider `t.co`: if you go through that page, the default policy applies.
... We need to deliver the policy together with the response.

dveditz: Why wouldn't you carry the original policy through the redirect chain?

jochen: What if you enter a URL into the address bar? No original policy.
... That forces default policy.

dveditz: If there is a policy, we need to decide which policy wins, right?

jochen: If you do a client-side redirect (e.g. load the page, then navigate yourself) you also get to choose the policy. We should take that into account.
... Ok.
... Still open: `ping-from` needs referrer policy definition.
... CSS's integration with Fetch is poorly defined.
... Will need to work with that group to understand/define the integration.

estark: One more open issue: JSON syntax for the `referrer-policy` header, maybe?
... Initially specced as a string, but maybe we want to be more flexible for the future.

mkwst: One suggestion was to use a quoted string, which would be forward-compatible with a JSON syntax in the future.

<bhill2> mkwst: one suggestion is to use a quoted string vs. bare string which would keep familiar syntax but be forward compatible

estark: I like that idea.

bhill2: When would you like to publish a new working draft?

jochen: Soon. Both Firefox and Chromium would like to ship the `referrerpolicy` attribute, as least what we have now.
... Requires spec tests to be present, but we should of course also update the draft.

bhill2: Two implementations that are going to ship, is it worth calling "level 1" done?

jochen: Anne proposed that we actually move most of this to the HTML spec. I dunno.
... I'd rather finish the few remaining points and see where we go from there.

bhill2: Would be good to get a heartbeat update out, since there are large sites using this in important ways.
... Reasonable stable spec is good for interop. Should publish a new WD update.

Subresource Integrity - starting work on Level 2

freddyb: Hi!
... Long list of things we intend to do.
... I think we ought to prioritize integrity policies. Have some interest inside Mozilla, which is helpful.
... Would require integrity for a certain set of HTML elements.
... Probably live in a different header, as far as I understood mnot's comments on the issue.

<francois> GitHub also expressed interested in SRI policies

freddyb: Would probably also want to support <meta> so we don't require a header. Interesting for CDNs (GitHub Pages, for instance)
... Other things: adding integrity to other elements.
... That's a bit tricky, since we don't want to block on the complete download before we do the hashing.
... Still needs research.
... Other things: signatures? public key for a resource?
... Might be other things: jww? francois?

bhill2: Would like to hear from UA implementers about things they're interested in implementing.

jww: From my perspective, I'm interested in what developers want. Signatures are one big thing. Downloads another.
... Pretty open to seeing how folks are using SRI in the next months, and building off of that.

francois: Would echo jww's comments.
... Important to see what might get adopted before we spec and implement features.
... We've heard that GitHub wants the policy stuff freddyb talked about.
... Also heard requests for support for images. Blocks progressive rendering.
... Might be fine for some use-cases.
... Would be helpful to have feedback from developers.

mkwst: Have you looked at agl's proposal for streaming? Merkle trees, etc? Long time ago.

freddyb: Seems like a good way to go. Don't remember the syntax.

jww: Talked with yoav about extracting SRI information to a central place in the page.
... Also. Caching. That's a big topic.

bhill2: Proxy vote on dev's behalf. He wants signatures. Dropbox is interested.
... Also good to to talk to about streaming syntax, as a purveyor of large files.
... All interesting cases. I like being driven by developer use cases. I think these topics are things we've had sporadic activity on the list now for a long time.
... Would be good to see a little more direction from editors.
... Pick one or two things to drive a spike through.
... Everyone has their priorities. If you have a good idea of a direction in which to lead the community, especially one which you'd implement, please do so.


opt-in CORS-like policy for intranet/internet bridging requests

<bhill2> mkwst: sent out a doc a week ago, premise is that intranet is distinct from internet

<bhill2> ... browser should not give one direct access to the other

<bhill2> ... we've had a formal distinction by RFC 1918 for a decade, haven't acted on it as a browser community

<bhill2> ... large number of devices that believe they exist in a bubble that doesn't include the internet

<bhill2> ... false of course, browser is a confused deputy pivot point between these worlds

<bhill2> ... routers are particularly problematic, history of CSRF attacks

<bhill2> ... also pieces of software hosted on users computer and grant excessive privileges, e.g. yesterday's TrendMicro vuln disclosure

<bhill2> ... tried a year or two w/ Mixed Content to block this

<bhill2> ... treating RFC1918 as mixed content subject to blocking

<jww> freddyb: I'll get back to work on the Bikeshed branch, but it's a little complicated because Dev and Francois (reasonably) requested that I do a pure conversion first without any textual changes, and my current branches has a number of (minor) changes.

<bhill2> ... objected to by developer community and removed

<bhill2> ... would like to revisit by using CORS preflight as an explicit opt-in for intranet resources

<bhill2> ... to talk to internet resources

<freddyb> jww: ah, right.

<bhill2> ... expect a new response granting access based on signalling the network type it is willing to talk to

<bhill2> ... I'm interested in experimenting in Chrome, need to look at network stack to see when and how we know about the network location

<bhill2> ... what I'd like to know is whether this is a problem that the group is interested in addressing

<bhill2> ... and is this mechanism appealing?

<bhill2> wseltzer: thanks for bringing this up, seems interesting to me

<bhill2> ... will need some developer advice because people will say "this breaks my internal development workflow"

<bhill2> ... need ways to do testing of sites and services that show up on intranets in development

<bhill2> mkwst: need to support developers, but we will break things, too

<bhill2> dveditz: have long wanted to do this, initial attempts have been shot down because of breakage

<bhill2> ... maybe we can get past it as a bigger group.

<bhill2> ... RFC1918 is a hack and the problem predates this

<bhill2> ... would be nice if we can open the possibility that UAs can add e.g. enterprise management features to do this more explicitly

<bhill2> mkwst: one piece of feedback is that proxies are an interesting way to do this, e.g. with a PAC file

<bhill2> bhill2: we should ask IE about this - very long history and lots of experience with this kind of thing (zones, proxies, intranet only settings, etc.)

<bhill2> ... maybe ask Eric Lawrence to weigh in

<bhill2> mkwst: also I would like help on how this works with IPv6

<teddink> I can also find folks in Edge (former IE, of course) as needed to help discuss the Zones issues, although Eric is a good resource as well.

<bhill2> mkwst: happy to come back to more complex things once we get the simple ones done

<bhill2> dveditz: from a spec thing would be nice to block the IP, at impl the layers were far apart and made it hard to block

<bhill2> ... and DNS game playing can make this hard to implement, too

<bhill2> dveditz: I believe that Opera did this...

<bhill2> mkwst: they did this in Presto, do not do it today

<bhill2> dveditz: would be interesting to hear feedback from their users

bhill2: Not to let the perfect be the enemy of the good, but:
... CORS + MIX only halfway blocks this attack.
... The attacks we're interested in can be accomplished with a redirect or navigation.
... The breakage we'd introduce by blocking navigation might be large. Much larger than treating it as mixed content.

<bhill2> mkwst: spec intends to cover navigation, that is both a concern and a challenge

dveditz: When we tried it, we blocked navigations. XHR was one way to do it, redirects were another.
... That's when we ran into problems where machines in the intranet...
... For a home user it worked well, more complex cases were less clearcut.

bhill2: I worry that this would break SAML and SSO systems.
... I want to go to externalportalformybenitits.com, redirects internally for token, redirects back out.

<bhill2> mkwst: yes, but hopefully it will be easy for such systems to opt-in

<bhill2> ... an alternative midpoint is to use an interstitial and have the user click OK

<bhill2> ... gives us runway to talk to vendors and get the products fixed

<bhill2> mkwst: I don't see this as a separate spec, I think it would be a note here and actual text would go into Fetch, Websockets, etc. but not be a normative resource here

<teddink> Thanks!

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/10 17:05:30 $