10 Aug 2016


See also: IRC log


dveditz, francois, estark, mkwst, terri, ckerschb_, teddink, gmaone


<dveditz> regrets bhill2

Agenda bashing

<dveditz> scribenick mkwst

Minutes approval

<dveditz> https://www.w3.org/2016/07/13-webappsec-minutes.html

<dveditz> no objections, minutes approved

<mkwst> dveditz: Objections?

<mkwst> everyone: <crickets>

<mkwst> dveditz: Approved!


<dveditz> https://irccloud.mozilla.com/pastebin/ZsivtKfe

<mkwst> dveditz: TPAC is coming!

<mkwst> ... Our meeting is 22nd/23rd (Thursday and Friday)

<mkwst> ... Wed is a plenary day.

<mkwst> ... Hotels go quickly. If you're going, book fast.

<mkwst> ... MIX is republished as CR.

<mkwst> ... https://www.w3.org/TR/2016/CR-mixed-content-20160802/

<mkwst> ... Hope to PR soon.

Call for Consensus: Stop work and transition 3 WD to Notes

<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0013.html

<mkwst> dveditz: No objections to moving three working drafts to NOTE.

<mkwst> ... CSP pinning, Entry Point Regulation, CSP Cookie Stuff

<dveditz> scribenick estark

Origin-wide policy manifest

<dveditz> https://lists.w3.org/Archives/Public/public-webappsec/2016Jul/0046.html

dveditz: origin-wide policy manifest came up
... is that different from feature policy?

mkwst: different thing entirely, "origin manifest" might be a better name
... feature policy is a specific policy delivered w/ a resource, applies to that resource. origin-wide policy mechanism applies to every page on an origin without 3-4k of a policy mechanism on every response
... manifest file on origins. response points to manifest. browser synchronously downloads and applies to response before rendering a page
... conceptually similar to policy URI mechanism in initial drafts of CSP, which FF implemented and shipped
... more broad, applies not just to CSP, to anything and everything delivered via HTTP headers
... enable changes to CORS, preflights on an origin-wide basis, a couple other things

<mkwst> https://lists.w3.org/Archives/Public/ietf-http-wg/2016JulSep/0351.html

mkwst: mark nottingham has a draft for a similar concept in http wg
... informs many origin policy things; his draft is more focused on header and delivery mechanism
... he's concerned with the manifest format, how it would interact with middleboxes in addition to server/browser
... mark thinks his format would be better for middleboxes
... and better for server implementors
... basic idea is the same, I need to sit down and figure out with mark what the advantages of each are

estark: performance? is server push the be-all-end-all?

mkwst: server push is the only thing that makes it viable. perf characteristics should be similar to delivering a header
... we'll have to experiment a bit
... doc doesn't require server push. practically speaking, big perf impact on initial request, probably wouldn't want to recommend without server push

dveditz: presumably after initial receipt it would be cached

mkwst: manifest file is an HTTP request like any other, it has cache headers served along with it
... hopefully will simplify implementation

dveditz: hope that we only end up with one of those features

<dveditz> estark: are we talking about making this for secure contexts only?

<dveditz> mkwst: that's how it's currently specified, I think it would be bad otherwise

mkwst: currently specified that way, bad to specify it otherwise

[CSP] Prevent nonce stealing

<dveditz> https://github.com/w3c/webappsec-csp/issues/98

<dveditz> https://github.com/w3c/webappsec-csp/issues/65

dveditz: issues in CSP spec about preventing nonce stealing
... whether it's practical to try to prevent, what the threat model is
... anne filed #65, suggesting we don't expose nonce to the page in the DOM
... artur filed #98 about dangling markup injection

mkwst: dangling markup in general would be amazing to solve
... interesting for things like ???, but secondary benefit
... small changes to parser which would neuter specific kinds of injection
... artur concerned with script injection
... if you inject a script before a nonced script, nonce could be applied to injected script rather than actual script
... if you have a src attribute and inline, reject the tag during parsing
... solves very specific problem of scripts, but not injecting a textarea along with a form
... would be great to have a more general solution

dveditz: another technique is if you find an angle bracket inside an open tag, reject that
... ultimately becomes topic for HTML wg, not us specifically

mkwst: solution will be in HTML, any ideas welcome

.opener and secure contexts

<dveditz> https://github.com/w3c/webappsec-secure-contexts/issues/42

dveditz: if you have an opener referring to an insecure context, does that make your context insecure?
... should we drop the opener, when can we drop the opener, is the current secure context spec too strict

mkwst: jake raised in context of service workers, which want to be able to control top-level navigation
... they want to drop opener for service-worker controlled top-level navigations
... marked as at-risk, would be nice if we could get rid of it, if security of new context did not depend on the way it was opened
... in status quo, this is what we should be doing, and SW folks are okay with currently described mechanism, given the work-around on their end
... will go to CR with current spec as written
... during CR period, figure out if there's something else we should do

dveditz: does chrome team have telemetry on use of opener?

mkwst: nothing that's useful. might have counter on window.open, but do not have counter on use of opener from a new context
... would be useful to add such telemetry, e.g. whether opener is being used same- or cross-origin, after top-level navigation or initial page, etc.

dveditz: and whether it's a open from window.open or link with a target

mkwst: we don't have that, would be helpful

dveditz: neither does FF
... would really like to get rid of opener

mkwst: some valid use cases, OAuth or OpenID
... 3rd party auth where it goes in a popup and you auth in the popup, uses opener to pass info back to page

dveditz: definitely cases in past where opener was used from popups, not sure about pages opened from a link

mkwst: would be good to find subsets we can disable
... maybe could make it explicit, not implicit, when you open a link
... need data to figure that out

is "localhost" a secure context?

<dveditz> https://github.com/w3c/webappsec-secure-contexts/issues/43

dveditz: FF implementation accepts localhost as a secure context in at least one context

mkwst: we accept localhost on stable as well, made this change relatively recently
... might be in beta, rolling through chrome's release train right now
... as long as there are resolvers that will send localhost to network for resolution, right thing is to treat localhost as non-secure
... what we agreed in f2f
... would be great if we could do what people expect and treat localhost as always loopback

dveditz: insecure for specific people in specific cases that page author woudl have no control of

mkwst: correct except that page author on localhost is probably same person administrating computer
... I'm concerned about only treating localhost as secure depending on what it resolves to
... should avoid that confusion
... page would work or not work depending on net configuration
... could add something like: if UA always resolves to loopback, then they can treat it as a secure context
... not the way our implementation works in Chrome
... could change all the RFCs to MUST, or not, in which case localhost should be non-secure

dveditz: but you said chrome in dev might be treating it as secure?

mkwst: no, in canary and dev and maybe beta, we treat localhost as non-secure
... in stable it's secure, in canary it's nonsecure, in-between who knows

dveditz: so shipping version treats localhost as secure?

mkwst: pretty sure, yes

dveditz: oh, so the issue is asking for it to go back to the way it was

mkwst: sympathetic to the idea, but only if we can change all the RFCs

estark: how does dns resolution in FF work? system resolver?

dveditz: yes, I believe so. our own caching, but not our own resolver
... for making security decisions, we don't know the DNS resolution at that point
... would be very hard for us to make the proposed change where we treat it as secure if it resolves to loopback
... might end up making changes to make that easier, because of protecting RFC1918 networks

estark: a bit of a mess in chrome; uses system resolver on some platforms, always resolves to loopback on other platforms but that causes problems for certain use cases

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/10/18 23:13:18 $