15:34:55 <RRSAgent> RRSAgent has joined #webappsec
15:34:55 <RRSAgent> logging to http://www.w3.org/2016/05/17-webappsec-irc
15:34:57 <trackbot> RRSAgent, make logs world
15:34:57 <Zakim> Zakim has joined #webappsec
15:34:59 <trackbot> Zakim, this will be WASWG
15:34:59 <Zakim> ok, trackbot
15:35:00 <trackbot> Meeting: Web Application Security Working Group Teleconference
15:35:00 <trackbot> Date: 17 May 2016
15:38:29 <wseltzer> s/Teleconference/F2F/
15:38:34 <wseltzer> rrsagent, this meeting spans midnight
15:38:39 <wseltzer> rrsagent, make logs public
15:38:48 <wseltzer> Chairs: Brad Hill, Dan Veditz
15:38:55 <wseltzer> rrsagent, make minutes
15:38:55 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
15:59:41 <bhill2> bhill2 has joined #webappsec
15:59:42 <dydz> dydz has joined #webappsec
16:03:28 <ejcx__> ejcx__ has joined #webappsec
16:08:50 <francois> francois has joined #webappsec
16:11:48 <wseltzer> -> https://www.w3.org/2016/05/16-webappsec-whiteboard.jpg Yesterday's whiteboard
16:12:07 <wseltzer> Agenda: https://docs.google.com/document/d/1KQ_TWHBc1QBn4Xf2yJ7AYDQumuJioaGDfxbzwIJjxOI/edit#
16:15:07 <estark> estark has joined #webappsec
16:17:25 <bhill2> rrsagent, make minutes
16:17:25 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html bhill2
16:21:19 <tanvi> tanvi has joined #webappsec
16:23:39 <tanvi> who's in for dinner?  maybe we should make reservations earlier today
16:24:49 <freddyb> +1
16:25:42 <deian> +1
16:26:18 <estark> +1
16:26:21 <bhill2> +1
16:26:48 <jww> jww has joined #webappsec
16:27:10 <jww> I'm in for dinner, do I need to write anything else?
16:27:20 <jww> is there a Zakim command for dinner?
16:27:35 <dveditz> jww: sorry, doesn't count without a "+1"
16:27:40 <tanvi> dinner: francois, freddyb, deian, mkwst, estark, bhill2, tanvi, jww for dinner = 8 so far.  looking on open table
16:27:42 <wseltzer> zakim, pick a dinner
16:27:42 <Zakim> I don't understand 'pick a dinner', wseltzer
16:33:30 <tanvi> I can get a reservation at La Fontine in Mountain View at 6:30 pm
16:34:34 <tanvi> http://www.yelp.com/biz/la-fontaine-restaurant-mountain-view
16:34:36 <tanvi> sound good?
16:34:45 <jww> tanvi: works for me.
16:35:32 <tanvi> okay done
16:35:38 <tanvi> parking may be tough
16:35:57 <tanvi> but 630 is fairly early so hopefully we will beat the crowds
16:44:12 <estark> thanks tanvi!
16:44:47 <JeffH> JeffH has joined #webappsec
16:45:26 <wseltzer> present+
16:45:28 <freddyb> present+
16:45:28 <bhill2> present+
16:45:29 <tanvi> present+
16:45:29 <JeffH> present+
16:45:32 <mkwst> present+
16:45:34 <francois> present+
16:45:34 <estark> present+
16:45:34 <jww> present+
16:45:35 <dveditz> present+
16:45:39 <bhill2> TOPIC: Referrer Policy
16:45:46 <devd> devd has joined #webappsec
16:46:14 <devd> Zakim: I am here!
16:46:20 <bhill2> estark: a policy you can set on a page or for an element to relax the restriction on referrer being withheld e.g. on https->http navigations
16:46:26 <artur_janc> artur_janc has joined #webappsec
16:46:30 <bhill2> ... or tighten policy to say never send a referrer
16:46:47 <bhill2> ... spec is ready to be wrapped up, don't feel there is any major work to be done
16:47:09 <bhill2> ... dominic denicola is working on the PRs to HTML to integrate it there and replace hand-wavey bits about that
16:47:21 <bhill2> ... that is the major outstanding work on the spec
16:47:33 <bhill2> ... in chrome there is a fair bit of implementation work to do to catch up with where the spec is
16:47:42 <bhill2> ... biggest work is implementing the header
16:47:46 <bhill2> ... moved out of CSP to new header
16:48:08 <bhill2> ... also added a referrer policy attribute to the link element
16:48:17 <bhill2> ... link tag (was already on anchor element)
16:49:01 <bhill2> ... this has been updated a bit to integrate better with fetch and service workers
16:49:16 <bhill2> dveditz: we proposed adding a couple of new states / policies
16:49:39 <bhill2> estark: hasn't been changed in the spec yet, don't know how strongly you feel about adding those
16:49:42 <bhill2> ... happy to add them to the spec
16:49:58 <bhill2> ... in terms of chrome implementation I can't say when we would implement them because catching up on the header is a bit of a project
16:50:01 <bhill2> ... that is higher priority
16:50:25 <wseltzer> https://w3c.github.io/webappsec-referrer-policy/
16:50:43 <bhill2> francois: pretty strongly.  spec meets all of our needs except the three new proposed policy states
16:51:24 <bhill2> ... spec covers everything else, seems unlikely there will be a V2 soon
16:51:33 <bhill2> ... don't want to leave these behind
16:51:59 <bhill2> dveditz: we've had internal settings to do this in Firefox for some time, and every user of that has wanted to restrict not expand
16:52:10 <bhill2> estark: but that's a different audience, users not resource authors
16:52:51 <bhill2> dveditz: but those same people have their own sites; interesting to them even if not big commercial sites
16:53:10 <bhill2> francois: recently we were talking to womens shelters, they can't do a lot because they're not super technical, but they were leaking referrers
16:53:24 <JeffH> what is francois' affiliation?
16:53:27 <bhill2> ... would like to be able to protect visitors to their sites, they use analytics internally and don't want to lose that with no referrer
16:53:31 <jww> jww has joined #webappsec
16:53:38 <bhill2> (jeffh: Francois is with Mozilla)
16:53:59 <bhill2> estark: sounds like we should probably add it, I personally won't have time to implement it for a while, maybe we can find someone else to implement it
16:54:03 <bhill2> ... maybe that's OK
16:54:10 <jww_> jww_ has joined #webappsec
16:54:17 <bhill2> dev: do we have data on how many have adopted it
16:54:28 <bhill2> mkwst: a lot... 7.3% of page views
16:55:52 <bhill2> francois: that's skewed by prominent sites
16:56:02 <bhill2> hillbrad: facebook uses origin-when-crossorigin
16:56:22 <bhill2> ... to protect privacy and avoid redirects
16:57:14 <bhill2> hillbrad: and we also user rel="noopener"
16:57:32 <bhill2> dveditz: is noopener being speced anywhere?
16:57:38 <bhill2> mkwst: yes, in the WHATWG HTML spec
16:58:13 <mkwst> https://html.spec.whatwg.org/#link-type-noopener
16:59:08 <bhill2> dveditz: would be nice if we could change so opener didn't give a ref unless explicitly wanted
16:59:38 <JeffH> https://html.spec.whatwg.org/#link-type-noreferrer
17:00:00 <bhill2> mkwst: probably very common with OAuth popups, return url navigates using that reference
17:01:11 <mkwst> https://github.com/w3c/webappsec-referrer-policy/pull/19
17:01:45 <bhill2> hillbrad: https://github.com/w3c/web-platform-tests/pull/2851
17:02:22 <bhill2> these are using the old CSP header, needs someone to adopt them and fix them up
17:02:46 <bhill2> (testsuite by @kristijanburnik)
17:03:22 <bhill2> mkwst: should we (is it enough) file bugs against the W3C HTML for these integration points that Dominic is doing?
17:03:34 <deian> deian has joined #webappsec
17:03:42 <bhill2> wseltzer: W3C normative reference policy is that they must be to things of equivalent stability and openness
17:04:00 <bhill2> ... goal is to have references in RECs be to W3C RECs or similar in other groups
17:04:27 <bhill2> mkwst: defines some hooks in to the navigation algorithm, maybe all in Fetch.   there is some integration into HTML to read the attributes as input to fetch
17:04:32 <bhill2> ... fetch calls back into referrer policy
17:04:49 <bhill2> ... would be good if wseltzer can look at that and help us figure that out
17:04:59 <bhill2> wseltzer: this is pretty well entangled, more so than SRI was
17:06:01 <bhill2> ... gold standard would be to get this in a W3C doc
17:06:08 <bhill2> mkwst: let's add this to our agenda
17:06:47 <JeffH> https://fetch.spec.whatwg.org/#referrer-policies
17:07:08 <bhill2> dev: do other browsers have a plan to implement the header version?
17:07:27 <bhill2> francois: we have someone working on the spec right now
17:07:35 <bhill2> mkwst: don't think FF has the CSP header
17:07:37 <bhill2> tanvi: we may already have it
17:09:42 <bhill2> mkwst: are we going to publish a new WD?
17:09:46 <bhill2> estark: yes, on my todo list
17:10:00 <bhill2> estark: may publish a WD from before the HTML integration started
17:10:06 <bhill2> ... as it may make more sense in that state
17:10:19 <bhill2> wseltzer: are you set up with automatic publication?
17:10:26 <bhill2> estark: mike sent me instructions so I should be
17:12:06 <bhill2> TOPIC: CSP3
17:12:23 <bhill2> mkwst: CSP3 doc at the moment is relatively stable, takes care of majority of things in CSP2 as well as a couple of new things
17:12:41 <JeffH> [ wrt referrer policy and HTML spec: https://html.spec.whatwg.org/#referrer-policy-attributes ]
17:12:41 <wseltzer> https://w3c.github.io/webappsec-csp/
17:12:43 <bhill2> ... couple of small changes I'd like to make, basically I split CSP into a couple documents and want to pull some things back from the document features
17:12:59 <bhill2> ... subdocument back into the main document, sandbox attribute, base uri, things already in CSP2
17:13:14 <bhill2> ... not enough to justify a separate document without making it more confusing to read
17:13:23 <bhill2> ... at the top of CSP there is a list of changes
17:13:44 <bhill2> https://www.w3.org/TR/CSP3/
17:13:50 <bhill2> ... frame-src and worker-src
17:14:00 <bhill2> ... in CSP2 we have child-src
17:14:16 <bhill2> ... in CSP3 we've split that out to frame-src and worker-src, which defers back to child-src
17:14:43 <bhill2> ... we need more granularity, the threat models may be similar, but people simply want to control them differently
17:15:03 <bhill2> artur: why are they similar?
17:15:10 <bhill2> mkwst: they have ability to execute code on an origin
17:15:22 <bhill2> artur: to me from a security perspective I would not normally need to restrict frame src
17:15:39 <bhill2> ... security effect from including an untrusted frame or untrusted worker
17:15:51 <bhill2> mkwst: I don't entirely disagree with you
17:15:57 <bhill2> ... I think they end up with very similar capabilities
17:16:50 <JeffH> where in https://w3c.github.io/webappsec-csp/ is the CSP3 spec ?
17:17:16 <bhill2> hillbrad: does child-src cover pop-ups and auxillary browsing contexts?
17:17:30 <bhill2> mkwst: not yet, my impression is there isn't strong support but people are interested
17:17:44 <bhill2> dveditz: there are lots of people who think they want to block navigation to stop exfiltration
17:18:44 <bhill2> hillbrad: would be nice to restrict to where e.g. ads can navigate to for e.g. "cloaking" scenarios to only accept known-good locations
17:19:04 <bhill2> dveditz: we would probably need UI to work on this
17:19:20 <bhill2> mkwst: not opposed, we just haven't done the work
17:19:35 <bhill2> dev: things like prerender, prefetch are also relevant
17:19:39 <tanvi> we haven't implemented referrer policy header yet but it is assigned and slated to happen soon
17:19:44 <bhill2> ... don't know if a declarative mechanism is the way to go long-term
17:19:49 <bhill2> ... maybe just service worker
17:20:07 <bhill2> mkwst: malvertising is concerned about navigations by an embedded context
17:20:17 <bhill2> ... want to know the landing page for an ad is the one they assessed
17:20:28 <bhill2> ... initial plan there was embedded enforcement
17:22:05 <bhill2> hillbrad: let's talk about this in the afternoon when Deian is back, this is needed for COWL, and we've talked about doing it only for iframes which covers his case and ads without so many of the UI issues associated with top level browsing contexts
17:22:19 <bhill2> mkwst: there were some changes to reporting that we talked briefly about
17:22:36 <bhill2> ... we are starting to use the new reporting API, idea is we're creating a single backend API that things like CSP can talk to
17:22:49 <bhill2> ... so CSP doesn't have to define this, can just refer to it
17:23:02 <bhill2> ... that spec is a bit in flux, issues like retries, retries across network state changes
17:23:12 <bhill2> ... good to have a central place to work out those issues
17:23:32 <bhill2> ... reporting also changed a bit such that we now should be able to give full url of page we are on as well of initial resource request (before redirects)
17:23:40 <bhill2> ... tried to load example.com?redirto=foobar
17:23:50 <bhill2> dveditz: do we tell them that it was a redirect?
17:24:06 <bhill2> mkwst: no, but you will know that because it is in your whitelist
17:24:23 <JeffH> mkwst has been relating items listed here: https://www.w3.org/TR/CSP3/#changes-from-level-2
17:24:29 <bhill2> estark: does this solve Zach's issue?
17:24:43 <bhill2> mkwst: no but I think what we will give will solve his issue, allowing tracking down the original link
17:25:16 <bhill2> ... no need to strip information that is available in JS already
17:25:35 <bhill2> dev: in an ideal world would be nice to know the origin of redirects at least
17:25:49 <bhill2> mkwst: I think we can have that conversation if you file a bug we can see what is possible
17:25:56 <bhill2> ... should be able to give more useful reports
17:26:26 <wseltzer> bhill2: regarding reporting, is it worth looking at imperative API to tune client-side?
17:26:42 <wseltzer> ... reporting is really useful, key in CSP adoption, and also really painful
17:27:07 <wseltzer> ... tuning reports; eliminating extensions, spurious reports
17:27:22 <wseltzer> ... imperative API to say "don't send reports on extensions"? or continue server-side?
17:27:37 <wseltzer> mkwst: if we could do a bretter job detecting extensions, you wouldn't need to suppress
17:27:54 <wseltzer> ... but it becomes complicated, e.g. event handlers callbacks
17:28:18 <wseltzer> ... we do have a handler that lets you send your own report
17:28:54 <wseltzer> ... let's figure out how to make the current stuff do what you want
17:29:27 <wseltzer> bhill2: can we reduce the pain and suffering about implementing CSP, so everyone doesn't have to write a blog post
17:29:41 <deian> deian has joined #webappsec
17:30:31 <bhill2> artur: unless you know the problem we are trying to solve, unsafe-dynamic may seem crazy
17:30:39 <bhill2> ... premise is you should trust the domains from which you load scripts
17:30:49 <bhill2> ... when CSP started it was maybe easier to meet that criteria
17:31:06 <bhill2> ... but it breaks down whenever there are several kinds of endpoints at origins you trust
17:31:15 <bhill2> ... two classes which are well known in pentester community
17:31:35 <bhill2> ... JSONP (json objects wrapped in callback functions that are attacker specified)
17:31:45 <bhill2> ... www.google.com/jsapi?callback=foo
17:32:14 <bhill2> ... second thing is "javascript gadgets" which take data from an unsafe location and uses that to look up a function of the window object and execute it
17:32:24 <bhill2> ... can also bypass CSP, Angular JS is one of those gadgets
17:32:39 <bhill2> ... if any of your script-src hosts have angular, you can use that to bypass CSP
17:33:04 <bhill2> ... there are a few other weird things people don't think about that let an attacker include as a script from an otherwise safe domain that lead to arbitrary script execution
17:34:47 <bhill2> ... very likely that if you include one of the most common script sources they have one of these bypasses available
17:34:52 <bhill2> dev: don't paths fix this?
17:35:11 <bhill2> artur: first of all you can bypass path restrictions with an open redirect (Homakov's bug)
17:35:43 <bhill2> ... we actually adopted a policy like this but it is very difficult to maintain in practice, especially for third party sources
17:35:50 <bhill2> ... few API owners will guarantee that paths don't change
17:36:06 <bhill2> ... e.g. the recaptcha API may load subresources that change locations
17:36:23 <bhill2> ... now loads from www.google.com/recaptcha2/... and your policy breaks
17:36:35 <bhill2> mkwst: will be a bigger problem once script modules are a thing
17:37:03 <bhill2> artur: in practice CSP probably has a whitelist that lets XSS still happen
17:37:17 <bhill2> ... but CSP already has an alternative - nonces and hashes
17:37:36 <bhill2> ... that may allow us to be much more granular about what is allowed to load
17:38:20 <bhill2> ... you can easily change templates to add this to script tags, one thing left is dynamic element creation in JS
17:38:32 <bhill2> .. unsafe-dynamic directive attempts to fix both of these
17:38:49 <bhill2> ... first it drops the whitelist, and then it adds trust dynamically to scripts loaded by a trusted script
17:39:02 <bhill2> tanvi: before a dynamically loaded script would have to be on the whitelist?
17:39:28 <bhill2> artur: yes, or it would need to explicitly get a nonce, but that requires deep changes to every JS API on the internet or some polyfill
17:39:48 <bhill2> tanvi: with unsafe-dynamic you ignore the whitelist
17:39:56 <bhill2> ... what about createElement
17:40:25 <bhill2> artur: this is allowed to happen; attacker could not do this because they don't control an entry point that could do this
17:41:09 <bhill2> mkwst: we look at whether it was parser inserted
17:41:31 <bhill2> ... we whitelist non-parser inserted scripts
17:43:01 <bhill2> dveditz: this is my least favorite part of the proposal
17:43:38 <bhill2> dveditz: could we make it its own directive that says ignore the script-src directive?
17:44:33 <wseltzer> bhill2: dynamic-nonce-enforcement?
17:44:57 <wseltzer> artur_janc: it's similar to unsafe-eval
17:44:59 <tanvi> document.createElement allowed, but document.write and innerHTML inserted scripts not allowed
17:45:35 <bhill2> artur: it is unsafe similar to eval, as an attacker if you control something in createElement, you get more control because you are not bound by the whitelist
17:46:42 <bhill2> hillbrad: this is good, calling it unsafe will stigmatize its use
17:47:07 <bhill2> mkwst: don't care about changing the name, creating a new directive complicates the policy parsing and enforcement mechanism
17:47:15 <bhill2> ... would have to special case
17:47:25 <bhill2> ... not sure it's any more convoluted than the current system
17:47:34 <bhill2> ... I don't like special cases
17:48:19 <bhill2> dev: you have to use a nonce this way; a different directive you could specify a specific named entrypoint
17:48:25 <bhill2> ... would have to be a separate directive
17:48:35 <bhill2> ... to specify it
17:48:43 <bhill2> ... personally just a fan of a new header
17:48:56 <deian> deian has joined #webappsec
17:49:25 <bhill2> ... in our case we would just list require.js
17:49:42 <bhill2> artur: you could already do that with a hash right now
17:49:52 <bhill2> ... give a hash to the loader script
17:50:24 <bhill2> ... many apps have a lot of both inline and referenced scripts
17:50:42 <bhill2> ... e.g. sensitive data that can't be externalized like JSON blocks in inline
17:50:55 <bhill2> dev: you can still use a nonce, but just not a fan of forcing you to use that
17:51:22 <bhill2> hillbrad: but a hash?
17:51:27 <bhill2> dev: would still have to use inline there
17:51:32 <bhill2> ... number of hashes might go up
17:52:30 <bhill2> dveditz: you could just put in a little inline bootstrap script
17:53:03 <bhill2> artur: it is a bit ugly, there is some precedent with nonces/hashes, etc..
17:53:45 <bhill2> hillbrad: don't think it's "ugly" just principle of least surprise
17:54:14 <bhill2> dveditz: syntax ratholes can go on forever
17:54:20 <bhill2> ... seems like everyone likes it
17:56:33 <bhill2> tanvi: a separate directive would be easier to implement
17:56:45 <bhill2> mkwst: for chrome it was significantly easier to not do a separate directive
17:57:01 <bhill2> dveditz: if a page has two policies, how does this combine?
17:57:08 <bhill2> mkwst: has to pass both
17:57:22 <bhill2> dveditz: that's right we don't combine, we just evaluate serially
17:58:03 <bhill2> mkwst: we've already implemented a few things, but easy to fix
17:58:19 <bhill2> artur: one thing we want to avoid is necessity to sniff user agents
17:59:40 <bhill2> TOPIC: unsafe-hash-attributes
18:00:01 <bhill2> artur: we experimented with the dynamic policies and it was easy because google is set up to add these nonces in its framework
18:00:11 <bhill2> ... two remaining blockers are javascript: uris and inline event handlers
18:00:36 <bhill2> ... didn't seem too crazy to allow hashes to also whitelist event handlers (js uris are less popular)
18:00:51 <bhill2> ... could remove a lot of pain for authors
18:01:02 <bhill2> jww: how would you deal with backwards compat?
18:01:20 <bhill2> artur: have to have unsafe-inline
18:01:27 <bhill2> mkwst: not backwards compatible as currently specified
18:01:44 <bhill2> ... currently hash in policy turns off unsafe-inline
18:01:54 <bhill2> ... then you put another policy that enables the inline event handlers
18:02:12 <bhill2> ... if you don't support this new directive, but do support hashes it will break
18:02:19 <bhill2> dveditz: who supports hash now?
18:02:55 <bhill2> chrome, firefox, safari tech preview
18:03:00 <bhill2> artur: but it is already broken
18:03:18 <bhill2> mkwst: we could have a new type of hash to enable it
18:03:27 <bhill2> dev: but then we couldn't have nonces either
18:05:05 <bhill2> mkwst: if you add a nonce today you don't get handlers
18:07:21 <bhill2> no way to do this backwards compatible with browsers that support nonce today
18:07:38 <bhill2> s/no way/...no way/
18:07:48 <bhill2> dveditz: could we make to also work with a nonce?
18:08:04 <bhill2> mkwst: could make first line of the onclick handler be a comment with the nonce
18:08:31 <bhill2> artur: benefit of a hash is we can pass over your app and tell you the hashes, but if you can make changes we can already outline scripts
18:10:50 <wseltzer> [short break]
18:10:53 <wseltzer> rrsagent, make minutes
18:10:53 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
18:13:05 <yoav> yoav has joined #webappsec
18:23:28 <wseltzer> mkwst: from my opinion, we can head to CR soon
18:23:33 <wseltzer> ... others should look at the stability
18:23:49 <wseltzer> ... remaining question whether we can use hashes to whitelist
18:24:15 <wseltzer> ... as we discussed with SRI, I'd like to figure it out
18:24:31 <wseltzer> ... if we're going to make a new directive for unsafe-dynamic, ...
18:24:43 <wseltzer> ... Please look at the spec, see if you're happy with it.
18:24:55 <wseltzer> ... Spend some quality time with CSP
18:25:27 <wseltzer> ... Good to see that W3C HTML folks are doing integration
18:25:41 <mkwst> https://github.com/w3c/html/pull/387 <--
18:25:47 <wseltzer> ... Travis landed a big commit closing lots of issues yesterday
18:26:51 <wseltzer> ... Let's get CSP to CR soon.
18:27:45 <wseltzer> JeffH: if you implement CSP2, do you replace with CSP3?
18:27:54 <wseltzer> mkwst: we've tried to design as backward-compatible
18:28:29 <wseltzer> JeffH: Do you say that explicitly in the spec?
18:28:36 <wseltzer> [it appears not]
18:29:10 <wseltzer> [rename the spec? john suggested removing "security" yesterday]
18:29:37 <wseltzer> bhill2: per the KFC precedent, we can just rename it CSP
18:30:02 <wseltzer> zakim, what color is the bikeshed?
18:30:02 <Zakim> I think Thulian pink
18:30:26 <wseltzer> TOPIC: Credential Management and Web Authentication
18:31:06 <wseltzer> bhill2: It would be good to discuss with Safari folks in the room
18:31:27 <wseltzer> TOPIC: SRI
18:32:18 <wseltzer> jww: SRI v1 is done
18:32:25 <wseltzer> devd: lots of users
18:32:42 <wseltzer> ... for v2, requests include cross-origin caching
18:33:24 <wseltzer> bhill2: Talk to your AC reps to support the PR
18:33:28 <JeffH> https://www.w3.org/TR/SRI/
18:33:42 <wseltzer> https://www.w3.org/2002/09/wbs/33280/SRI-PR/
18:33:56 <wseltzer> ^ the poll, open to AC reps
18:34:13 <wseltzer> francois: there is an issue on the list. One of the notes is probably wrong
18:34:21 <wseltzer> ... can we remove it?
18:34:29 <wseltzer> mkwst: notes are non-normative
18:34:54 <wseltzer> francois: regarding origins for data URIs. We'll remove it.
18:35:40 <wseltzer> jww: Everything else is V2
18:35:49 <wseltzer> ... require-sri-for
18:36:04 <wseltzer> freddyb: pull request
18:36:22 <wseltzer> ... I have a draft implementation for FF
18:36:37 <wseltzer> ... github interested
18:37:05 <wseltzer> ... they had integrity for all scripts minus one, they were sad not to have a way to enforce
18:37:19 <wseltzer> jww: overall, I'm a fan, but someone pointed out it's tricky to use without reporing
18:37:31 <wseltzer> ... because resources will stop loading unexpectedly
18:37:38 <wseltzer> francois: but there's CSP reporting
18:38:11 <wseltzer> https://github.com/w3c/webappsec-subresource-integrity/pull/32
18:38:41 <wseltzer> devd: my concern is that historically, SRI was for CDNs
18:39:07 <wseltzer> ... so I'm not sure what require-integrity gets us
18:39:33 <wseltzer> ... corporate proxy
18:39:57 <wseltzer> dveditz: what if it were require-integrity for these domains?
18:40:10 <wseltzer> jww: we've had people request straight require
18:40:22 <wseltzer> devd: I don't think we have full sample of the people who need it
18:40:30 <wseltzer> ... uncertainty about how it integrates in CSP
18:41:12 <wseltzer> jww: what this gets is something similar to upgrade-insecure. you don't need it in a perfect word
18:41:16 <wseltzer> ... helps you transition
18:41:39 <wseltzer> ... it's not solely about CDNs, lots of people have different uses
18:41:49 <wseltzer> ... we envisioned other future uses, like caching
18:42:10 <wseltzer> ... sounds useful, also like complexity I'm wary of adding without user demand
18:42:23 <wseltzer> devd: we should spend more time thinking about it
18:42:44 <wseltzer> ... a better story around SRI-CSP integration
18:42:53 <wseltzer> ... think about cross-origin caching
18:43:02 <wseltzer> jww: we're talking about experimental
18:43:27 <wseltzer> freddyb: implementing doesn't mean it's locked in
18:43:53 <wseltzer> ... require-sri-for scripts, does that include same-origin scripts?
18:44:01 <JeffH> is pull/32 related to issues/23 ?
18:44:02 <wseltzer> ... what is it defending against?
18:44:36 <wseltzer> devd: some sites with separate hosts
18:45:03 <wseltzer> francois: lots more complexity
18:45:31 <wseltzer> bhill2: edge caching with integrity protection could be useful
18:45:50 <wseltzer> ... say that things on our CDN are OK so long as they're integrity-tagged
18:46:17 <wseltzer> devd: a set of issues that are CSP-SRI integration; consider them together
18:46:40 <wseltzer> ... are lots more people interested in this directive?
18:47:17 <wseltzer> bhill2: might be more useful in report-only than enforce mode
18:47:48 <wseltzer> freddyb: maybe put it out behind a flag, get feedback
18:48:01 <wseltzer> jww: make sure it's forward-compatible
18:48:18 <wseltzer> dveditz: next on list, add integrity attribute for processing of inline scripts
18:48:58 <wseltzer> ... Crispin or Daniel mentioned yesterday
18:49:27 <wseltzer> ... Integrity for downloads
18:50:01 <wseltzer> mkwst: firefox handled encoding differently
18:50:22 <wseltzer> bhill2: if you block it, the user will just copy the link to the URL bar anyhow
18:50:39 <wseltzer> ... how do you make the UI meaningful? do they get to bypass, what signal do they get?
18:50:47 <wseltzer> ... usability
18:50:58 <wseltzer> francois: we might have existing UI for safe browsing
18:51:10 <wseltzer> jww: integrity is a network error, currently
18:51:17 <wseltzer> mkwst: the browser's gonna browse
18:51:46 <wseltzer> ... a download isn't represented in the page
18:52:09 <wseltzer> bhill2: do you have any way to get integrity feedback on your downloads?
18:52:20 <wseltzer> dveditz: it's a navigation
18:52:57 <wseltzer> mkwst: what happens is opaque to the page
18:53:27 <wseltzer> ... there should be no impact of failrue, but agree with brad that's a problem
18:54:38 <wseltzer> devd: this emphasizes how hard it is to download safely on the web
18:55:54 <wseltzer> jww: also cross-origin issues
18:56:19 <wseltzer> mkwst: it would have to require CORS as well
18:57:11 <wseltzer> devd: if we add anchor integrity, we also need to add CORS
18:57:23 <wseltzer> francois: or we don't do the reporting
18:57:32 <wseltzer> jww: there's lots of challenge here
18:57:47 <wseltzer> francois: to summarize: outstanding problems 1) reporting,
18:58:19 <wseltzer> ... UI is a question for the browser, "your download is corrupt"
18:58:31 <wseltzer> bhill2: layer 8 problem, knowing your download links are broken
18:59:04 <wseltzer> dveditz: are we proposing that for a elements, you have download, integrity; enforce, if it fails say it's corrupt?
18:59:14 <wseltzer> jww: not sure re telling user
18:59:45 <wseltzer> ... if many of these things are corrupt, imagine all the errors to the user
19:00:09 <wseltzer> devd: rather than warning, just fail it. no user decision
19:00:21 <wseltzer> ... up to UA to handle the failure
19:01:20 <wseltzer> dveditz: apart from the warning, do we agree?
19:01:22 <wseltzer> jww: not yet
19:01:52 <wseltzer> dveditz: what we do with failures, what we tell users, CORS issue
19:01:59 <wseltzer> JeffH: what's the use case?
19:02:23 <wseltzer> dveditz: you link to downloads hosted elsewhere, on CDNs
19:02:36 <wseltzer> bhill2: CDNs for downloading open source packages
19:03:02 <wseltzer> JeffH: use case to make statement about the bag of bits, say "these two things need to match when downloaded"
19:03:33 <wseltzer> freddyb: regarding reporting; if we have no reporting, it's easier, but there's no way for website to know there's a problem
19:03:46 <wseltzer> ... and we don't know hwo users respond
19:04:08 <wseltzer> devd: I'm ok with that, because if you're a site using anchor tags for download, you already have that problem
19:04:35 <wseltzer> ... so many sites have iframe to do the download, iframe post-messages to say network error, retry
19:04:47 <wseltzer> ... that's a better way to do it already
19:05:18 <wseltzer> dveditz: add integrity to iframes?
19:05:22 <wseltzer> mkwst: I wanted that
19:05:37 <wseltzer> ... would be nice for ads, "I audited this"
19:06:08 <wseltzer> jww: you can do that with fetch already
19:06:17 <wseltzer> ... modulo CORS
19:07:36 <wseltzer> freddyb: performance issues if you wait for integrity
19:08:19 <wseltzer> devd: integrity for downloads; next steps, consider reporting
19:08:32 <wseltzer> ... and if not, just network error if integrity fails.
19:08:41 <wseltzer> jww: only if we can find a way to make onerror work
19:09:01 <wseltzer> ... I want the site to be able to see that there was a network error
19:09:13 <wseltzer> [then we have to do the CORS checks]
19:09:36 <wseltzer> jww: let's talk more
19:09:52 <wseltzer> JeffH: as CORS is currently wired into SRI
19:10:05 <wseltzer> freddyb: this is a navigation
19:10:16 <wseltzer> mkwst: navigations go through fetch
19:10:29 <wseltzer> ... need to change HTML to pass attributes through
19:11:03 <wseltzer> tanvi: you're saying don't do onerror, Dev?
19:11:08 <wseltzer> devd: yes, that's easier
19:11:14 <wseltzer> ... it fails as a network error
19:11:23 <wseltzer> ... but no reporting
19:12:40 <wseltzer> devd: as a site owner relying on a CDN for downloads, I get a call if the CDN is down; no call if the CDN gets hacked, today
19:12:51 <wseltzer> ... I'd rather get a call in the second instance too
19:13:39 <wseltzer> JeffH: as a user, I'd like to see "integrity check passed"
19:13:52 <wseltzer> tanvi: you could put it in the console
19:14:14 <wseltzer> mkwst: dangerous to add UI that makes some links look better, new incentive for malware authors to decorate their links
19:14:51 <wseltzer> JeffH: trying to get to the use case
19:16:11 <wseltzer> devd: it gives value to the web app author: users are getting what I sent them
19:16:17 <wseltzer> ... it's not a user-facing feature
19:17:03 <wseltzer> JeffH: if you've downloaded and integrity fails, you shouldn't save to disk
19:17:23 <wseltzer> francois: for safebrowsing, we don't move to download until checked
19:18:04 <wseltzer> dveditz: you could send the hash to malware scanning
19:18:12 <wseltzer> ... if it's the right format hash
19:18:31 <wseltzer> mkwst: if it fails, send the failure to safebrowsing too
19:19:29 <wseltzer> francois: if you tell authors to use the hash safebrowsing supports, can speed up the safebrowsing test
19:19:35 <wseltzer> [lunch, resume at 1]
19:19:39 <wseltzer> rrsagent, draft minutes
19:19:39 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
19:20:08 <wseltzer> i|[short break]|scribenick: wseltzer
19:20:10 <wseltzer> rrsagent, draft minutes
19:20:10 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
19:21:00 <wseltzer> i|estark: a policy|scribenick: bhill2
19:21:03 <wseltzer> rrsagent, draft minutes
19:21:03 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
19:38:02 <yoav> yoav has joined #webappsec
19:59:59 <deian> deian has joined #webappsec
20:00:29 <artur_janc> artur_janc has joined #webappsec
20:01:03 <estark> estark has joined #webappsec
20:07:34 <tanvi> second call for dinner
20:07:45 <tanvi> anyone who didn't rsvp in the morning who wnats to come?
20:07:48 <bhill2> TOPIC: SRI
20:07:52 <bhill2> TOPIC: cross-origin caching
20:08:12 <bhill2> jww: agreement this is a good thing, but there are complexities
20:08:14 <bhill2> dveditz: clarify?
20:08:22 <bhill2> jww: yes, thing is in cache, skip network
20:09:22 <bhill2> dev: CSP bypass / cache-poisoning: attacker injects content with a hash claiming one origin, but it's not really on that origin
20:09:35 <bhill2> ... but browser includes it as-if-from-that-origin because there's a matching cache entry
20:09:59 <bhill2> johnwilander: but if resource has been loaded once from that origin?
20:10:08 <bhill2> ... but any subsequent one you are allowed to take the hash
20:10:32 <bhill2> dev: but then the biggest advantages are lost
20:10:42 <bhill2> jww: there is an advantage, but destroys the bootstrapping effect
20:10:50 <bhill2> johnwilander: but it's "really" the first time
20:11:03 <bhill2> dev: but caching algorithm here is forever
20:11:57 <JeffH> JeffH has joined #webappsec
20:12:15 <bhill2> dveditz: how many hashes do you keep?
20:12:26 <bhill2> dev: probably everyone uses sha256 and just keep those hashes
20:12:28 <yoav> yoav has joined #webappsec
20:14:47 <bhill2> hillbrad: can we just add this to response to a HTTP HEAD request?
20:15:22 <wseltzer> i/TOPIC: cross-origin caching/scribenick: bhill2
20:15:25 <bhill2> dev: we could, but since attack is only for CSP, maybe we can add a new directive that says "I accept this risk"
20:16:12 <bhill2> dev: or just add hashes to CSP policy, then it doesn't matter, you're allowed to use that file anyway
20:16:30 <bhill2> johnwilander: but my load once suggestion was to avoid the privacy issue of seeing if someone's ever been there
20:17:12 <bhill2> francois: also works in reverse, reference files that don't exist on your server and see if they load
20:17:26 <bhill2> jww: yes, it's a timing attack but its a "use once"
20:17:35 <bhill2> francois: not in the case that I referenced
20:18:39 <bhill2> francois: you can return a value that doesn't go into the cache, so you don't destroy the signal
20:19:01 <bhill2> francois: <integrity="hash-of-jquery" src="do404.cgi">
20:21:49 <JeffH> potential descriptive names: cross origin content-based cache retrieval  -- content aware storage policy -- cache aware storage
20:25:38 <bhill2> francois: explains attack at whiteboard
20:25:55 <bhill2> dev: only do it for crossorigin anonymous
20:27:31 <bhill2> jww: but the pattern of what's in your cache may allow fingerprinting collectively
20:27:36 <yoav> yoav has joined #webappsec
20:27:37 <bhill2> dev: it already works, this makes it easier
20:27:55 <bhill2> dev: attackers can work hard, developers don't want to
20:28:27 <bhill2> francois: not clear this will give us a real boost, real fingerprinting consequence
20:29:48 <bhill2> dev: but there is lots of developer interest
20:30:17 <bhill2> jww: also would be neat to do shared-library style automatic upgrade
20:30:36 <bhill2> jww: also problems with crazy headers Eduardo found, e.g. what if you set cache expiration to something low like 0
20:30:52 <bhill2> ... set refresh url to javascript:doEvil()
20:31:40 <bhill2> ... need to do research on this, don't even know what it means to ignore a header
20:31:59 <bhill2> dveditz: there may be headers like CSP that come with a frame (e.g. if we do this for iframes)
20:32:20 <bhill2> artur: also content-encoding, same response may have different properties
20:32:42 <bhill2> mkwst: would this also require a preimage?
20:32:54 <bhill2> jww: no, you give a real thing but set bad headers on it
20:33:31 <bhill2> hillbrad: is there any data?
20:33:50 <bhill2> mkwst: talked to Elie Burzstein about it, what would it look like with an infinite cache
20:34:22 <bhill2> jww: also about how often do people see something the first time, request something expired
20:35:01 <bhill2> johnwilander: WebKit also has cache partitioning to create distinct caches from different origin requests; a compile time flag that safari uses
20:35:05 <deian> deian has joined #webappsec
20:35:05 <bhill2> ... it's a privacy feature
20:35:25 <bhill2> artur: firefox extension back in the day had "safe cache" but it had big performance concerns
20:35:35 <bhill2> francois: tor browser has this
20:37:29 <bhill2> TOPIC: W3C normative reference policy
20:37:34 <Zakim> Zakim has left #webappsec
20:37:51 <bhill2> wseltzer: this is a w3c process / work mode discussion
20:38:06 <bhill2> ... as part of the process when something reaches REC, it and the things it refers to are stable and have gone
20:38:29 <bhill2> ... through open standards processes and have compatible intellectual property status, and are compatible with the open web
20:38:57 <bhill2> ... we do a lot of work here with WHATWG and have good relations with them
20:39:12 <bhill2> ... but Fetch and their HTML aren't being developed by the same processes used at W3C
20:39:24 <bhill2> ... no stable snapshots to assure that links always point at the same place
20:40:09 <bhill2> ... so for SRI going to PR we had to assert that the group would continue to monitor Fetch and make sure that references pointed to the current stat of that document
20:40:48 <bhill2> ... one approach of the i18n group is to take snapshots of the Encoding spec and making references to the snapshots
20:41:08 <bhill2> ... that would be one way to do that
20:41:21 <bhill2> ... and also would give the patent commitments from this group
20:41:51 <bhill2> ... I am trying hard to make this not just be extra work and procedural hurdles but also about assuring that these important
20:42:05 <bhill2> ... components of the stack are things we are looking at and comfortable about the process by which they've developed
20:42:28 <bhill2> ... we need to address these because as further specs move forward we will get these questions from the Director and need
20:42:35 <bhill2> ... good answers on the normative reference policy
20:42:42 <bhill2> dveditz: CSP is for example more dependent on Fetch
20:42:48 <wseltzer> -> https://www.w3.org/2013/09/normative-references Normative Reference Policy
20:43:02 <bhill2> mkwst: I think they both have similar relationships, there are mutual hooks
20:43:20 <bhill2> ... we do have normative references to concepts in Fetch to make those algorithms work
20:43:29 <bhill2> ... so I think the relationship there should work
20:43:55 <bhill2> ... HTML is more difficult in a number of ways, involves bidirectional requirements
20:44:09 <bhill2> ... is very duplicative and doing work in one place doesn't flow into another without effort
20:44:25 <bhill2> ... not the same as encoding spec, not just a snapshot where there is one editors draft
20:44:31 <bhill2> ... seems reasonable to do with Fetch
20:44:37 <bhill2> ... less likely that it would work for HTML
20:44:42 <bhill2> dveditz: it explicitly didn't it forked
20:45:57 <bhill2> mkwst: what I have been doing is sending patches to WHATWG HTML and then filing bugs against W3C saying "we landed this over here, please make it make sense in your version"
20:46:14 <bhill2> ... but documents have diverged in various ways that make it difficult for me to assert the same patch has the same meaning
20:46:26 <bhill2> ... I don't want to commit to doing that review twice because it is hard enough to do it once already
20:46:43 <bhill2> francois: and it would be a lot of work to patch W3C HTML
20:46:53 <bhill2> mkwst: we could go the other way, but not the one I've chosen
20:47:15 <bhill2> ... WHATWG HTML is the doc that I read and am familiar with how it works, closer working relationships
20:47:19 <bhill2> dveditz: and things happen
20:47:44 <bhill2> mkwst: I think that model could work for Fetch if Anne is happy with it and somebody volunteers
20:48:02 <bhill2> wseltzer: do we have support for doing that?
20:48:13 <bhill2> deian: I'd like to try, would volunteer to do that
20:48:24 <bhill2> dveditz: is there w3c version of service workers?
20:50:39 <bhill2> bhill2: how much work is involved in porting between formats
20:50:51 <bhill2> mkwst: I think anne would support porting upstream to bikeshed
20:52:17 <bhill2> jww: are there other specs we will have to do this for?
20:52:28 <bhill2> room: DOM, WebSockets, URL....
20:54:08 <bhill2> dev: has there been concern about SRI and its references for implementers?
20:55:09 <bhill2> deian: I think there is still some disconnect between Firefox implementation and Fetch, e.g. the CSP integration points as described don't work that way yet in Firefox
20:55:42 <bhill2> dev: I don't remember stability of fetch being an issue at implementation time for SRI
20:56:24 <bhill2> johnwilander: I don't know the status of Fetch work, but I can find out; if we have any opinion we'd like to share I can find that out
20:56:58 <bhill2> mkwst: fetch API is behind a runtime flag in STP, but it is more than just the API
20:58:56 <wseltzer> TOPIC: WebAppSec and the IETF
20:59:32 <wseltzer> scribenick: dveditz
20:59:40 <Zakim> Zakim has joined #webappsec
21:00:01 <dveditz> johnw: I'm referencing shellshock here so you can see the timeframe we started thinking about this
21:00:37 <dveditz> ... 3 common headers that don't cause a pre-flight in CORS, but which aren't restricted with what characters can go into them (in practice)
21:01:01 <dveditz> ... these three headers could be used then to trigger the shellshock vulnerability, for example
21:01:54 <dveditz> ... I talked to the people involved and browser vendors decided to go with a lax character definition
21:02:17 <_devd_> _devd_ has joined #webappsec
21:02:17 <dveditz> ... that goes beyond the RFC of allowed header characters.
21:03:00 <dveditz> ... I would like to see browsers restrict the headers of these three fields specifically, RFC 2616 section 14.1
21:04:45 <mkwst> https://tools.ietf.org/html/rfc7231#section-5.3.2
21:05:19 <dveditz> JeffH: 2616 is obsolete now
21:05:25 <yoav> yoav has joined #webappsec
21:05:33 <dveditz> mkwst: but the new one is the same thing wrt this issue
21:06:19 <dveditz> john: how should we proceed
21:06:32 <JeffH> https://en.wikipedia.org/wiki/Shellshock_%28software_bug%29
21:07:38 <dveditz> mkwst: I think you're asking that we verify the fetch "safe" headers against a stricter set, not all http headers
21:08:00 <dveditz> john: yes
21:08:14 <dveditz> mkwst: fetch seems like a reasonable place to do that
21:09:00 <dveditz> john: second topic: associated domains
21:09:10 <wseltzer> rrsagent, draft minutes
21:09:10 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
21:10:11 <rbarnes> rbarnes has joined #webappsec
21:10:30 <dveditz> [on whiteboard: { apple.com, icloud.com, filemaker.com} {google.com, google.ru, youtube.com}
21:11:12 <dveditz> ... we are struggling to make SSO work within these groups. Technically SOP says they are separate origins, but they are related with a single account that works across them
21:11:45 <dveditz> ... Users expect things to work across these because in their mind (branding) they are the same company
21:12:24 <dveditz> mkwst: there's already a plist format for
21:12:47 <dveditz> ... Google solves the same problem differently. the Play store keeps a list of origins
21:13:26 <dveditz> ... we could solve the binding problem. My concern is the degree of laxness between them. what features do you want to enable between them?
21:13:28 <deian> q+
21:14:10 <dveditz> john: we could (assuming all sites opt-in) we could allow cookies across them, or our various storage partitions could group
21:14:24 <dveditz> JeffH: we have 9 use cases in the problem statement for DBOUND in the ietf
21:14:43 <dveditz> ... it's a hard problem to get alignment on solutions.
21:14:47 <wseltzer> https://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/?include_text=1
21:15:36 <dveditz> ... cookies are just one piece. there's also various UI indicators. The only real notion today is the "effective TLD" (aka public suffix list)
21:16:01 <dveditz> ... maintained by Mozilla. Doesn't track the reality on the web. there's a timelag
21:16:32 <dveditz> dveditz: the list doesn't bind things together, it'
21:16:57 <dveditz> .. it's more to keep sites MORE separated than they might otherwise be (e.g. no blogger.com cookies)
21:17:36 <dveditz> JeffH: it's not just the web, there are other usecases (mail, tls... )
21:17:59 <dveditz> ... the current scheme (eTLD) doesn't allow one to express those relationships. There are 4 proposals in the DBOUND working group
21:19:00 <dveditz> ... IMHO two are [less workable]. the other two are one from  andrew sullivan's and myself, and the other by John Levine who's also been around a long time
21:19:00 <wseltzer>  as "work in progress."
21:19:05 <wseltzer> https://datatracker.ietf.org/wg/dbound/documents/
21:19:08 <dveditz> ... both approaches put signalling in the DNS
21:19:13 <wseltzer> s/as "work in progress."//
21:20:19 <dveditz> ... This is important and needs to get done, but we've been struggling along without it for so long so people are working on the "more important" daily urgencies
21:20:37 <artur_janc_> artur_janc_ has joined #webappsec
21:20:59 <bhill2> q+
21:21:01 <dveditz> ... It will take a bunch of work to get it done in terms of spec and convincing people
21:21:04 <wseltzer> q+
21:21:08 <wseltzer> q+ on layer-crossing
21:21:27 <dveditz> ... then the question is who will bother to deploy this. Andrew and I are convinced this signalling needs to be in the DNS
21:21:29 <yoav> yoav has joined #webappsec
21:21:29 <rbarnes> rbarnes has joined #webappsec
21:21:33 <dveditz> mkwst: does this require DNSSEC?
21:22:00 <dveditz> JeffH: well, if you want to trust it. I'm not sure I'd put that into the spec because we've been able to muddle along without it
21:22:34 <dveditz> rbarnes: that's because we have TLS, and if you need real security you use that. if you're making security decisions based on it then you will need DNSSEC
21:23:01 <dveditz> JeffH: andrew is confident ICANN will be interested in deploying this, mandating it for top-level domains
21:24:30 <dveditz> ... A huge chunk of what the public suffix list denotes is the distinction between these domains and the public
21:25:10 <dveditz> ... Would places like blogger or appspot pick this up to make the distinctions between delegated authorities
21:26:13 <dveditz> mkwst: I'd like to see the problem statements and who would use this. There's much already baked into Chrome making distinctions between origins
21:26:57 <wseltzer> ack deian
21:26:58 <dveditz> deian: I think some of the disjointness and combination you are describing could be denoted by COWL labels
21:27:27 <JeffH> dbound problem statement https://datatracker.ietf.org/doc/draft-sullivan-dbound-problem-statement/
21:27:41 <JeffH> https://datatracker.ietf.org/wg/dbound/documents/
21:27:49 <dveditz> ... we currently don't allow delegating privileges [not understanding]
21:28:13 <dveditz> john: that's a new thing. SOP is in place but COWL will let you do additional things?
21:28:15 <dveditz> deian: yes
21:28:47 <dveditz> jww: sounds like your idea is to change the security boundary from "origins" to "organizations".
21:29:04 <dveditz> ... couldn't you do much of what you want with postMessage?
21:29:17 <JeffH> https://datatracker.ietf.org/wg/dbound/documents/
21:29:29 <dveditz> john: privacy is one of our interests. there are 200 something orgs involved in loading cnn.com
21:30:08 <bhill2> q?
21:30:10 <dveditz> ... if google.com is talking to google.ru it's the same organization, if it's google and apple then they are distinct
21:30:27 <dveditz> jww: it's hard, but you can do this today with postMessage
21:30:47 <dveditz> john: things like cache partitioning can't be done with postMessage!
21:30:51 <wseltzer> ack bh
21:31:10 <dveditz> bhill2: I've been thinking about this for over a decade and I'm concerned about the implications here
21:32:14 <dveditz> ... In the beginning I worried about wanting additional priv's (like SSO) would require letting big sit4s like google/facebook set cookies or other things on your domain. market pressure on small sites to comply
21:32:24 <wseltzer> s/implications/implications and economic incentives/
21:32:39 <dveditz> john: no, this is "does facebook own this domain" are they the same
21:33:21 <dveditz> bhill2: we need to make sure this doesn't create financial incentives to collapse the privilege separation on the web. we might end up with very large sets that undo the security boundaries we are trying to set up
21:33:43 <dveditz> ... We need to keep in mind the unintended consequences
21:34:24 <dveditz> _devd_: why isn't icloud.com isn't on icloud.apple.com ? we already have a mechanism for sharing at the domain level
21:34:42 <dveditz> ... why _do_ sites create .ru/.de versions?
21:34:47 <dveditz> mkwst: lawyers
21:35:09 <bhill2> q?
21:35:35 <dveditz> jww: amazon/audible is an example of joining, but there are organizations that divorce, too.  Ebay/paypal for example
21:35:43 <dveditz> JeffH: all that is supported in the current drafts
21:35:47 <bhill2> ack wseltzer
21:35:47 <Zakim> wseltzer, you wanted to comment on layer-crossing
21:36:00 <dveditz> wseltzer: I've been watching DBOUND as it struggles to get cycles/traction
21:36:22 <JeffH> q+
21:36:30 <dveditz> ... Worth spending a little more time if this is meaningful.
21:37:02 <dveditz> john: we could set up our own format "you need to set up a manifest, maybe even signed, and we'll allow you to do more things"
21:37:15 <dveditz> ... and that might become a Safari only thing
21:37:43 <dveditz> mkwst: it would be really helpful if you documented what you want to get out of this. I understand the grouping together, but not what features you are trying to get
21:37:56 <JeffH> https://tools.ietf.org/html/draft-sullivan-domain-origin-assert-02
21:38:00 <dveditz> john: originally we were making more distinctions, not less
21:38:12 <dveditz> ... we don't want to kill Google SSO for example
21:38:35 <dveditz> JeffH: there's also more than one SOP
21:38:47 <JeffH> https://tools.ietf.org/html/draft-levine-dbound-dns
21:38:58 <dveditz> john: 3rd party cookie blocking is a classic example here -- these aren't 3rd parties to each other
21:39:04 <dveditz> ... but to browsers they are
21:39:27 <wseltzer> q?
21:39:34 <dveditz> deian: the motivation for parts of COWL are wanting to split maps and search on the same domain, for example
21:39:47 <dveditz> mkwst: depends on which features are being enabled
21:40:26 <dveditz> john: we are not opposed to google.com and youtube.com working together flawlessly
21:40:39 <dveditz> bhill2: what about facebook connect and some random site?
21:40:49 <dveditz> john: those are true 3rd party relationships
21:41:07 <dveditz> bhill2: I'm as concerned about the things you want to break as well as the things to are unbreaking
21:41:21 <dveditz> s/to are/you are/
21:41:37 <dveditz> ... what are the things that will break that you know about
21:42:01 <tanvi> q?
21:42:16 <dveditz> francois: we have a concept like that in Firefox where for tracking protection we don't block google-analytics on google.com or youtub.com, but on other domains we do block it as a tracker
21:42:19 <tanvi> q+
21:42:51 <dveditz> jww: we don't need to tie these things together to ...
21:43:50 <dveditz> francois: brad's point was excellent. we have a built in list, but if it's a one-way mapping on sites themselves people could opt-in to all kinds of things
21:44:32 <dveditz> bhill2: if you block things that people want they will find workarounds. sites LIKE analytics, it pays the bills, tells them what's working
21:44:52 <wseltzer> q+
21:45:08 <dveditz> john: there's friction here -- browsers treat these sites as separate and they aren't organizationally or in user's minds
21:45:35 <dveditz> JeffH: this is not what the user wants, this sharing is what "google" wants or "facebook" wants
21:45:58 <dveditz> jww: the user may want the "fast login" enabled by this, without knowing what's underneath it
21:46:28 <dveditz> ... there might be an incentive to group things (by sites) to make things easier or more performant, but makes things less secure for the user
21:47:16 <wseltzer> ack JeffH
21:47:18 <dveditz> john: we already see sites that tell users to disable 3rd party cookie blocking because two formerly separate sites joined, but now the user has disabled 3rd party blocking for the entire web
21:47:23 <dveditz> ... this is a real case
21:48:03 <dveditz> JeffH: andrew and i and john levine have been talking about this for a long time as a basic enabler at the DNS level. how it gets used is another matter and up to the implementations at levels above
21:48:48 <dveditz> ... policy is hung on domain names currently, with a crude understanding of what a domain name maps to. setting up this basic concept could enable a bunch of things to be build on top
21:49:39 <tanvi> taking myself off
21:49:40 <tanvi> ack tanvi
21:49:42 <bhill2> q?
21:49:42 <dveditz> ... Establish capabilities at the most basic realm and see what people can do with it. whether or not the "web" invents an equivlent mechanism as you're talking about here, I think it still needs to exist at a lower level too
21:50:17 <wseltzer> s/taking myself off//
21:50:19 <dveditz> deian: this seems interesting to me but I'm still not sure how it would be used. some cases my be solved  in COWL and some might not
21:50:45 <dveditz> john: look at network traffic after a google login to see what they have to go through to make this work
21:51:18 <dveditz> _devd_: that's the opposite use case -- google WANTS it to be separate, on accounts.google.com, to protect that data from other related domains
21:52:30 <dveditz> john: we are not opposed to SSO on related Google domains, but when we turn the screws on 3rd party cookies they have to go through all sorts of gymnastics -- postMessage and iframes and such -- to make it work
21:53:29 <dveditz> you can only be owned by one domains -- so a tracker couldn't claim to be owned by everyone.
21:53:46 <dveditz> ... we envision a tree structure with apple.com at the top
21:54:17 <dveditz> ... I don't think we wwould go the "relaxing" route, maybe we would,
21:54:39 <dveditz> JeffH: I've heard from google folks that there's magic in chrome to make some of this work for them
21:56:04 <dveditz> wseltzer: sounds like the next steps have to happen at a lower level, the ietf group for example
21:56:16 <dveditz> JeffH: it doesn't have to, the web could have an equivalent
21:56:46 <dveditz> wseltzer: if it's established at a lower level we can then think about how we could safely use it at the web layer
21:57:02 <dveditz> JeffH: I put links in the minutes, comments appreciated
21:57:24 <dveditz> john: but it sounds like this is 3 ? years out? I heard DNSSEC mentioned....
21:57:24 <bhill2> q?
21:57:48 <dveditz> JeffH: I don't think there should be guidance necessarily that there must be DNSSEC to have a SOFA record
21:58:00 <wseltzer> q-
21:58:10 <wseltzer> s/SOFA/SOPA/
21:58:22 <dveditz> ... Ultimately you won't have a flag day to roll this out, but you could build this list by awlking the DNS and build it that way
21:58:37 <dveditz> ... instead of a manual interaction
21:58:55 <dveditz> john; another way to do this is to crowdsource it
21:59:02 <dveditz> JeffH: not sure I understand
21:59:34 <dveditz> john: if you're creating a new restriction, like the Disconnect list -- 'ok this broke, so we crowdsource this exception'
21:59:59 <dveditz> ... could we define a mechanism then the sites could do it officially rather than having to do crowdsourcing it
22:00:34 <dveditz> bhill2: we're at time. I think next steps would be define what privileges you want to enable. heard that request from several people
22:02:23 <wseltzer> Topic: Credential Management and Web Authentication
22:02:24 <dveditz> next topic: Credential management and web authentication
22:02:24 <bhill2> TOPIC: Credential Management and Web Authentication
22:05:32 <wseltzer> rrsagent, draft minutes
22:05:32 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
22:08:38 <wseltzer> Present: Dan Veditz, Brad Hill, Joel Weinberger, Emily Stark, Francois Marier, Frederik Braun, Tanvi Vyas,
22:08:41 <wseltzer> Mike West, Wendy Seltzer
22:09:30 <wseltzer> present+ Artur_Janc, Jeff_Hodges, John_Wilander, Deian_Stefan, Richard_Barnes
22:09:37 <wseltzer> zakim, list attendees?
22:09:37 <Zakim> I don't understand your question, wseltzer.
22:09:43 <wseltzer> rrsagent, list attendees
22:09:43 <RRSAgent> I'm logging. I don't understand 'list attendees', wseltzer.  Try /msg RRSAgent help
22:09:48 <wseltzer> zakim, list attendees
22:09:48 <Zakim> As of this point the attendees have been Dan, Veditz, Brad, Hill, Joel, Weinberger, Emily, Stark, Francois, Marier, Frederik, Braun, Tanvi, Vyas, Artur_Janc, Jeff_Hodges,
22:09:51 <Zakim> ... John_Wilander, Deian_Stefan, Richard_Barnes
22:10:25 <wseltzer> mkwst: Credential Management spec
22:10:33 <wseltzer> ... Chrome is going ahead with current, imperative version
22:10:36 <dveditz> mkwst: there's a credential management spec for a couple years. Chrome is going ahead with the imperative spec, with good feedback from MattN and others.
22:11:22 <dveditz> ... all the same properties apply. the API is more or less the same as last year
22:11:34 <dveditz> ... fairly generic, high level
22:11:57 <dveditz> ... store, get, require user intermediation
22:12:20 <dveditz> ... shipping in Chrome 51(?), the one right after GOogle I/O
22:12:42 <dveditz> ... a number of external companies interested, kayak, the guardian, clipboard... folks are experimenting
22:12:58 <dveditz> ... seem unhappy it doesn't give them access to everything, and requires a secure context
22:13:14 <dveditz> ... and that it requires asynce fetch()
22:13:39 <dveditz> ... they're excited about the idea of doing it async--hadn't thought about it before--but short term pain due to some of the restrictions
22:13:48 <dveditz> ... seems successful for the folks trying it out
22:14:03 <dveditz> ... hope the UI witll be acceptable to users, will be monitoring it carefully
22:14:26 <dveditz> ... maybe in 6 weeks or so we can give you an idea how it's going
22:15:36 <dveditz> ... We'll talk about it a little at I/O and show examples of it layered on top of existing sites (use fetch, then navigate to the page where it would have posted the login)
22:15:42 <dveditz> bhill2: does this work cross-origin?
22:16:41 <dveditz> mkwst: hm, no. within an eTLD+1 we'll allow a user to choose a stored pasword, but not to automatically submit it until a user has chosen it once
22:17:00 <dveditz> ... we still limit this to the top-level page, not frames,
22:17:21 <dveditz> ... we're trying to be restrictive at first and maybe we can loosen things later
22:17:43 <dveditz> ... the paypal in-frame case is totally legit but we want to move slowly
22:18:16 <dveditz> ... it's difficult to explain to users what's going on -- why is something asking for my paypal credentials on store.com? is it legit?
22:18:39 <bhill2> q?
22:18:43 <bhill2> q+ johnwilander
22:18:53 <bhill2> q+ bhill
22:19:01 <dveditz> tanvi: you said if the user didn't have a login for that domain you'll prompt for it?
22:19:44 <dveditz> mkwst: no, related domains. if you had a login stored for foo.example.com and then bar.example.com wants a credential we'll show the user they have a foo.example.com login and let them choose it
22:20:04 <dveditz> ... not allowing example.com to say "hey, I accept the google.com login!"
22:20:48 <wseltzer> q+ johnwilander
22:20:56 <dveditz> MattN: one of my concerns is the multi-login account, when you have a twitter and a facebook account and a site accepts either
22:21:45 <dveditz> ... if you've used one you're only shown one, but it's unclear that if you cancel you coiuld then log in with the other account
22:21:57 <dveditz> ... I don't want to "cancel" I'm trying to log in. not intuitive
22:22:21 <dveditz> mkwst: we're still working on the UI here, talked about offering an "other login" option instead of "cancel"
22:23:35 <wseltzer> ack john
22:23:41 <bhill2> ack johnwilander
22:24:05 <dveditz> ... the site is responsible for the UI. if it thinks you're in the log in state it needs to distinguish between "I don't want to log in" vs "I don't want one of these"
22:24:40 <dveditz> john: are you doing something about legacy HTTP auth in this group? Especially log-out is an unsolved problem
22:24:53 <dveditz> mkwst: I agree with richard, the less I think about http auth the happier I am
22:25:26 <dveditz> rbarnes: we just added telemetry and it looks like 1/4 times users use http auth it is an insecure connection
22:25:55 <dveditz> john: I would like a better, but still native support for web authentication
22:26:08 <dveditz> wseltzer: you ought to join our web auth WG then :-)
22:26:15 <bhill2> q?
22:26:39 <dveditz> john: cookies for auth is terrible and we've been trying to save it with HttpOnly and secure and other kinds of things.
22:26:44 <JeffH> q+
22:27:09 <dveditz> bhill2: is there any API (now or future) to ask "am I eTLD with foo.com"
22:27:21 <dveditz> mkwst: no such proposal, but could be done
22:27:33 <tanvi> telemetry on type="password" security - http://mzl.la/1XxVG9H
22:27:38 <bhill2> mkwst: could add to URL spec
22:27:46 <dveditz> bhill2: currently the way to do that is for a site to pull in it's own copy of the public suffix list, and no guarantee it's the same list used by the browser
22:27:48 <wseltzer> ack bhill
22:27:59 <dveditz> JeffH: using this UI does not manifest a browser-implemented browser UI
22:28:11 <dveditz> mkwst: it does!
22:28:26 <MattN> q+ to discuss the initial login capture
22:28:54 <dveditz> ... the page calls get() in a way that will not show UI (log in if log in available), or it can call it in a way that will show UI to the user using native UX
22:28:58 <tanvi> 45% of login pages are over HTTP.
22:29:23 <dveditz> tanvi: pages with logins, or percent of times users submit logins?
22:29:47 <tanvi> pages with logins
22:30:21 <dveditz> tanvi: I ignore http logins, so I see every page on a site with a login box. If I logged in then those boxes wouldn't be there, lowering the count for an arguably worse situation
22:30:22 <wseltzer> q?
22:31:15 <dveditz> MattN: one of the other issues is the initial registration. that's still being typed into the form and reduces some of the security benefit
22:31:24 <dveditz> ... since it's not going into browser UI
22:31:51 <JeffH> q?
22:31:54 <JeffH> q-
22:31:59 <wseltzer> ack MattN
22:31:59 <Zakim> MattN, you wanted to discuss the initial login capture
22:32:06 <dveditz> ... Part of the point of this API is to have security properties. If we're not helping the initial web registration we're missing a benefit
22:32:35 <dveditz> mkwst: there was the "write-only" proposal that would help, too, but there didnt' seem to be much interest in implementation
22:32:55 <dveditz> rbarnes: write-only?
22:33:17 <dveditz> mkwst: a field that couldn't be read by the page, only submitted by forms. there were more subtlies involved
22:33:37 <dveditz> ... not sure what would happen with service workers (maybe punt? bypass?)
22:34:11 <dveditz> MattN: I still find it unusual how this async login works when sites could just submit a form like they usually do
22:34:39 <dveditz> ... maybe requiring write-only would be a way to add this to the existing flow/model
22:34:54 <dveditz> ... for sites who don't want to use the fetch/navigate approach
22:35:33 <dveditz> bhill2: I was in a conversation with accessibility folks about password fields saying "star star star star".
22:36:33 <dveditz> ... do we need to be concerned about that with this feature as well?
22:37:13 <dveditz> ... how often do people synthesize their own "password-looking" field to work around this or other issues?
22:38:55 <dveditz> tanvi: you're proposing that for password cred. we fill into the existing forms rather than separate UI?
22:39:02 <dveditz> MattN: I think that would be better, yes.
22:39:26 <JeffH> https://w3c.github.io/webauthn/
22:39:33 <dveditz> mkwst: do we need to integrate credential management with Web AuthN or are we going our separate ways?
22:39:53 <dveditz> JeffH: here's the "unofficial" draft (not FPWD yet, but what we're working on)
22:40:23 <dveditz> ... impedence mismatches I found over lunch, and we both have a credential object but the semantics are different
22:40:51 <dveditz> .... I don't know the full backstory why we pulled out the abstraction we did that was based on an earlier rev of credential management
22:41:04 <dveditz> ... need to resolve within the Web AuthN WG
22:41:36 <dveditz> ... is the WAN interface semantically the same as the credential management interface, I'm not sure
22:42:01 <dveditz> ... We used DOMString in various places that have gone to buffersource and  ...
22:42:07 <tanvi> q?
22:42:11 <tanvi> q+
22:42:25 <dveditz> mkwst: you have a different credential interface that's named the same credential interface -- we can't do that
22:42:37 <dveditz> ... we can merge, or we can rename one of them
22:43:05 <dveditz> ... one reason CM is so abstract is so it could take in things other than just passwords
22:43:33 <dveditz> JeffH: we need to up-level this between the two groups. there's no technically reason they couldn't be more tightly bound
22:43:49 <dveditz> rbarnes: either they need to converge/align, or they need to really diverge
22:44:00 <dveditz> JeffH: agreed
22:44:13 <dveditz> mkwst: at least not using the same names for different things
22:44:36 <dveditz> rbarnes: to what extent does  CM add value to asymmetric things like Web AuthN?
22:45:31 <dveditz> mkwst: having CM give you a representation of the credential and have future things hang off it. I'm not sure what's easiest for developers. my first instict was that having one thing for "auth stuff" would be best, but maybe a different API for passwords vs. auth would be better
22:45:45 <dveditz> JeffH: doesn't seem like the impedence mismatch is that high -- they are similar.
22:45:52 <dveditz> mkwst: we should talk
22:45:56 <MattN> q+
22:46:05 <dveditz> JeffH: is there value in the convergence?
22:46:33 <dveditz> ... basic state is we're going to FPWD real soon now, call for consensus is out. maybe later June
22:46:49 <dveditz> ... polishing this summer
22:47:02 <dveditz> mkwst: Microsoft is already doing this?
22:47:13 <dveditz> JeffH: they have an implementation in Edge. something that is demoable
22:47:56 <dveditz> ... have you looked at Web Auth N, john?
22:48:27 <dveditz> john: no, we've talked to Mike about CM. this isn't in webkit this is in Safari land, interacting with keychain and so on
22:49:19 <dveditz> ... I've been talking to the folks mike talked to. If this is now an API it will move password management into webkit from "safari"
22:49:39 <dveditz> ... please send/re-send me emails
22:49:52 <dveditz> tanvi: are you interested in doing this?
22:50:31 <dveditz> john: I woiuld say yes, but traditionally this is part of the safari team and as a webkit representitive I can't say so definitively without talking to them
22:50:39 <dveditz> tanvi: is there website demiand for this?
22:51:17 <dveditz> mkwst: I'm talking to a few folks who have imeplemented using this on their sites. I have the impression sites like it when users log in, and making it more frictionless is liked better
22:51:35 <dveditz> JeffH: the notion of federated is a shared secret?
22:52:24 <dveditz> mkwst: no, currently we only save which login the user used last time but we don't log in for them
22:52:35 <MattN> q?
22:52:46 <dveditz> ... would love to do something like that. need to come up with some kind of trusted browser UI to be used for this
22:53:28 <dveditz> devd: is there a mode I can find out "if the user had a credential that could be used now"
22:53:40 <dveditz> mkwst: no, we don't share whether the user has credentials or not
22:53:46 <tanvi> ack tanvi
22:54:09 <dveditz> ... lots of people want to know that (avoid prompting if there isn't a login already) but I don't know a good (safe) way to share that info
22:54:28 <dveditz> devd: do you know how many users store how many passwords?
22:55:41 <dveditz> MattN: this api is giving sites a new way to interfere with password management by storing bad information. is there a way to block sites that behave badly?
22:55:56 <dveditz> mkwst: we mitigate this by involving the user
22:56:11 <dveditz> MattN: but the user doesn't see the password, it could be junk and not the real password
22:56:24 <dveditz> jww: we have evidence they do this from autocomplete=off
22:57:01 <dveditz> bhill2: ok, next topic
22:57:11 <dveditz> Topic: COWL
22:57:18 <rbarnes> fwiw: Firefox password manager fills a password ~15% of the time
22:57:26 <bhill2> https://github.com/w3c/webappsec-cowl/wiki/May-17-F2F-meeting
22:57:29 <rbarnes> (and no, i'm not sure what the denominator is)
22:58:00 <dveditz> deian: joel and I talked about what parts of COWL we could implement that would be most useful
22:58:35 <dveditz> ... COWL supports "labels" for information that can segregate it
22:58:56 <dveditz> ... pages can delegate privileges to share information
22:59:24 <dveditz> ... once you read sensitive data you are tainted with that label. read data from "b.com" and you can't leak it back to "a.com"
22:59:36 <dveditz> ... Reduces the authority that the page would have
23:00:52 <dveditz> ... this isn't to deal with malicious code, but to reduce leakage or hacking of well-intentioned origins
23:01:11 <dveditz> ... Our last feedback was not using origins for our labels
23:01:20 <MattN> rbarnes: not sure where you got that data from but Fx has saved logins for 27% of login forms visited
23:01:29 <dveditz> ... Now we're using origins, unique origins, and @@
23:02:15 <dveditz> ... The other main feedback is to make the serialized labels look like [origins?]
23:03:03 <dveditz> ... The new model requires an iframe to have taint, so top-level pages can always be navigated
23:03:44 <dveditz> ... when you create a combined iframe you lose access to some APIs
23:04:11 <dveditz> ... that's a simpler deplyment scenario and more backwards compatible if we change it later
23:04:45 <dveditz> bhill2: gives us more future flexibility, we can add new features and say they only apply in certain circumstances
23:05:38 <dveditz> deian: if you do turn on confinement in a page mid-way through it's hard to remove access in the DOM in chrome, easier in Firefox
23:05:49 <dveditz> mkwst: it's easier to reason about if it's more static
23:06:01 <dveditz> deian: I'll keep that in mind sa we refine this
23:06:35 <dveditz> ... briefly looked at the service worker spec. if we think of it as a proxy we can make this work.
23:08:02 <dveditz> ... there are other things brough up -- leaks by resizing iframes. hard to address
23:08:35 <devd> devd has joined #webappsec
23:08:45 <dveditz> ... inclined to punt this to a future version since this is a covert channel and there are others
23:09:46 <dveditz> ... if we require it to be static that simplifies the implementation
23:10:08 <dveditz> ... Nicholas is about half way through rewriting the FIrefox patch to the new approach
23:10:32 <dveditz> ... for Chrome if we can intergrate COWL and suborigins we might be able to get some of the features in pretty easily
23:10:54 <dveditz> ... With COWL google.com isn't isolated from google.com/maps
23:12:01 <dveditz> jww: I think it's fair to say sub-origins is a subset of COWL except for the asymmetry
23:12:28 <dveditz> ... there are "bite sized" chunks of implementation we could do, and some of them are similar and we could make them match
23:13:14 <dveditz> deian: we required integrity and condidentiality, but many times the integrity label was empty. I propose that we set a sensible default and not make people specify it all the time
23:13:31 <dveditz> Topic: sub-origins
23:13:36 <dveditz> q?
23:13:38 <bhill2> q?
23:13:41 <dveditz> ack mattn
23:14:17 <dveditz> wseltzer: if we have a new editor we need to get him official as an invited expert
23:14:41 <dveditz> jww: sub-origins is a way of defining a namespace within the scheme-host-port origin tuple
23:15:41 <dveditz> ... we have a draft spec that covers most of the issues that needed to be covered. clearly some areas still need clean up
23:15:43 <JeffH> https://w3c.github.io/webappsec-suborigins/
23:16:02 <dveditz> ... Chrome has a spec-complete implementation behind a flag (with a couple holes -- cookies,)
23:16:13 <dveditz> ... cookies don't follow the SOP anyway and add complexity
23:17:05 <dveditz> ... there are times when you would want to share cookies. but since one of the usecases is protection from less trusted sections of the same domain we _don't_ want to share cookies.
23:17:36 <dveditz> ... there's no great short-term solution (can provide a doc of the various attempts). Spec presents the option we think makes the most sense
23:18:01 <tanvi> q+
23:18:05 <dveditz> ... cookies are attached to the same host/port sent over HTTP. but document.cookies would be empty
23:19:09 <bhill2> dveditz: is it a same origin XHR?
23:19:25 <dveditz> ... you could simulate cookies using local storage
23:19:27 <bhill2> jww: no, a suborigin request is not same origin with the same scheme/host/port
23:20:00 <dveditz> ... up to the server to not send cookies to a suborigin it doesn't want that suborigin to know
23:20:17 <dveditz> tanvi: couldn't you just set the cookie locally for that suborigin?
23:20:28 <dveditz> devd: but what network request to you attach it to?
23:21:01 <dveditz> tanvi: key the cookies off the whole suborigin
23:21:20 <dveditz> devd: what do you _send_ with the request? you don't know the suborigin until you get the response back
23:21:43 <dveditz> jww: we think for most cases this is the best option
23:22:01 <dveditz> tanvi: could do a pre-flight and then send only the right cookies
23:22:13 <dveditz> devd: we could, we'll look at feedback on this
23:22:40 <dveditz> jww: we have to trust the server, the server is what sends us the suborigin header
23:23:03 <dveditz> dveditz: what about the origin specified in postMessage?
23:23:12 <dveditz> jww: spec has a serialized format for that
23:23:30 <dveditz> devd: we also have unsafe-postMessage
23:23:44 <dveditz> ... that sends to the whole origin
23:24:15 <dveditz> artur_janc: we tested this on a crazy set of extensions with safe and unsafe cookies
23:25:17 <dveditz> jww: there are a large number of apps where the cookie is totally untrusted and it's fine to see all the cookies. server can specify unsafe cookies and then document.cookie will be populated
23:26:06 <dveditz> artur_janc: still respecting httpOnly, of course. with this approach we found most applications continued to work, whereas blanking document.cookie broke things
23:28:01 <dveditz> jww: there's symmetry with sub-origins
23:28:33 <dveditz> devd: could put a wordpress "admin" area in a sub-origin so a comment XSS can't reach into it and do bad things
23:31:02 <tanvi> q?
23:31:04 <tanvi> ack tanvi
23:31:13 <dveditz> john: I agree it would be nice to segregate cookies, but if you spent all day discussing it there are probably some gems in there we can learn from
23:31:26 <dveditz> jww: I'll take an action item to share our working document
23:32:33 <dveditz> artur_janc: there's the unsfae mode we talked about, and for safe mode we could treat it as a separate origin
23:33:10 <dveditz> john: If I'm example.com with a hardcoded resource
23:33:20 <bhill2> johnwilander: if I'm example.com and have a hardcoded subresource to example.com and move my main page to a suborigin, what happens
23:33:20 <dveditz> ... main page is in a sub-origin. what happens?
23:33:27 <bhill2> dev: fetch will be cross-origin
23:33:36 <bhill2> johnwilander: in safari that will be 3rd party and cookie won't be sent
23:33:50 <bhill2> dev: yes, shouldn't be treated that way
23:33:56 <bhill2> johnwilander: yes but if it's a new origin...
23:34:11 <bhill2> jww: as I said, thanks to cookies suborigin cant be platonic ideal of a new origin
23:34:25 <bhill2> johnwilander: for our case would be equivalent of opening in a clean-slate private browsing tab
23:34:37 <bhill2> dev: but you want it to work with some cookie sharing
23:35:04 <bhill2> dveditz: can we differentiate between domain cookies and host cookies?
23:35:15 <bhill2> dev: for dropbox we don't set a domain
23:35:22 <bhill2> dveditz: you'd have to for suborigins to see it
23:36:00 <bhill2> jww: setting of cookies is also concerning, don't want suborigin to be modifying cookies of another origin which breaks the symmetry you'd like a bit
23:36:17 <bhill2> artur: right now subdomains can mess with your cookies, suborigins are supposed to mirror that someway with less effort
23:36:26 <bhill2> ... we can debate how much more we want out of suborigins than subdomains
23:36:40 <bhill2> wseltzer: why are we not trying to fix the brokenness of cookies?
23:37:01 <bhill2> artur: it is difficult to get infinite subdomains; caching, dns latency, apps stop working on a subdomain because urls break, links break
23:37:09 <bhill2> ... in practice a very breaking change to move to a subdomain
23:37:41 <bhill2> ... having a more lightweight mechanism that lets you do a server side change with a header and options is much lower bar for engineering effort
23:37:51 <bhill2> wseltzer: so trying to port some things over and avoid cookies mess
23:38:07 <bhill2> dev: but I want it to be as much like a completely different origin as possible
23:38:16 <bhill2> ... don't want to recreate the subdomain mess around cookies
23:38:16 <wseltzer> s/avoid cookie mess/avoid fixing cookie mess/
23:38:48 <bhill2> dev: this is being fixed by the host cookie prefix
23:39:59 <bhill2> jeffh: you can't just change how cookies work without breaking the web, I chaired the WG that wrote the RFC
23:40:12 <bhill2> ... we documented behavior, got noncompliance fixed and closed it
23:40:23 <bhill2> ... but going to reopen with Mike's work
23:40:49 <bhill2> jww: so there are efforts to fix, but we're also trying to deal with current world in a backwards compatible way here
23:40:56 <bhill2> ... sandbox was too pure and harmed the ability to use it
23:41:18 <bhill2> johnwilander: would not be surprised if some of us end up betting on password/credential autofill and just wiping cookies every now and then
23:42:04 <bhill2> tanvi: you'll still need to deal with this in v2
23:42:15 <bhill2> dev: browser just treats all requests as cross-origin
23:42:23 <bhill2> tanvi: doesn't seem like a fixable problem
23:42:46 <bhill2> jww: goal was a set of behaviors which we believe will help a lot of applications in a huge number of cases
23:42:57 <bhill2> ... wouldn't be surprised if there were other strategies needed for other applications
23:43:27 <bhill2> johnwilander: have you considered adding an attribute to cookies; only cookies with suborigin attribute get shared
23:43:39 <bhill2> jww: would be excited about that at some point, not sure about v1
23:43:53 <bhill2> dev: impacts adopting, needs more server changes, makes sense to build it up over time
23:44:15 <bhill2> artur: we've spent hours/days on this, and I am 100% comfortable using this on google.com with the unsafe-cookie mode
23:44:26 <bhill2> ... I think we get substantial improvement even with cookies being shared with suborigins
23:44:56 <bhill2> ... good to have ways to make it more strict for some apps, but in practice apps that use http only auth cookies, they will be much safer with suborigins
23:45:25 <bhill2> dev: being able to write to a cookie from a compromised suborigin allows only session fixation, nothing else
23:45:40 <bhill2> ... vs. e.g. getting access to csrf token if document.cookie was readable
23:45:49 <bhill2> artur: current proposal addresses both modes
23:46:13 <bhill2> johnwilander: but Google would be fine with the cookie flag because you could set that and it would work
23:46:26 <bhill2> tanvi: Google doesn't care because auth cookie is http only
23:46:33 <bhill2> deian: why not use different cookie jars?
23:46:43 <bhill2> dev: if you have multiple cookies with same name which do you send?
23:46:53 <bhill2> artur: makes it very unclear to developers what cookie is sent where
23:47:24 <bhill2> ... difficult to reason about what will be sent, which will be readable in document.cookie, may be mismatches from what you see in document.cookie and what actually is sent to server
23:47:39 <bhill2> jww: from an implementer perspective would be extremely difficult to do that in chrome
23:47:58 <bhill2> ... networking stack would need to be involved and taught about suborigins, vs. just as a web platform layer feature
23:48:15 <bhill2> johnwilander: we already have names about such conflicts with subdomains
23:48:19 <bhill2> dev: and they do confuse people
23:49:02 <bhill2> jeffh: yeah, it's gnarly
23:49:45 <bhill2> ... as long as changes are backwards compatible we can make necessary modifications
23:50:00 <bhill2> jww: I don't think choices made about cookies are bad, they are the choices that were made
23:50:37 <bhill2> jeffh: there has been some thought on reworking idea of state management
23:50:44 <tanvi> we can call it crackers
23:50:47 <bhill2> ... through perhaps lack of cycles, etc.
23:52:41 <bhill2> bhill2; there was an "HTTP State Management" WG in the IETF ~3-4 years ago, their work was ultimately irrelevant because no browser vendors showed up and cared
23:52:46 <deian> deian has joined #webappsec
23:52:52 <bhill2> ... but you could go look at that and implement if you think ideas were good
23:53:56 <bhill2> bhill2: IETF effort I'm thinking of was HTTP Authentication not State Management
23:54:23 <bhill2> jeffh: and there were some experimental RFCs and it's in the record now and demonstrated that there was little browser interest in having a notion of authentication wedded to the HTTP protocol
23:54:29 <bhill2> q?
00:02:48 <wseltzer> TOPIC: SRI
00:03:48 <bhill2> TOPIC: SRI
00:04:00 <bhill2> jww: somebody brought up a use case we can't support today
00:04:09 <bhill2> ... edge CDN, superfast but less well protected as a physical site
00:04:30 <bhill2> ... if not all UAs support that, you don't want to load from that CDN if integrity is not present
00:04:45 <bhill2> ... you can do it programmatically, but has lots of problems
00:04:59 <bhill2> ... it would be cool to have a way to do it declaratively
00:05:09 <bhill2> ... original spec had noncanonical-src which we didn't do
00:05:12 <bhill2> ... freddy is not a fan
00:05:25 <bhill2> rbarnes: can you elaborate what this would look like
00:07:10 <jww> bhill2: original motivation was proxies messing with resources
00:07:39 <bhill2> johnwilander: did you consider if adding the hash to the URL
00:07:49 <bhill2> ... if you want it to fail when not supported
00:08:03 <bhill2> dev: no, developer wants it to work everywhere, but only use the sketchy CDN if you know about integrity
00:08:37 <bhill2> jww: issues with programmatic polyfill outweight the benefits
00:09:42 <bhill2> bhill2: it could just be a canary, users with browsers that do it can report to protect users that don't
00:09:52 <bhill2> ... but you could just change based on user agent
00:10:31 <bhill2> dev: you can get preload scanner benefit by doing a link rel preload at the head
00:11:01 <bhill2> dev: or just do UA detection
00:11:17 <bhill2> jww: person with this use case thinks user agent sniffing may work
00:12:14 <bhill2> freddyb: friends who are pentesters like getting more scanners to break with more src-like attributes
00:12:23 <bhill2> dev: also preload scanners won't catch it
00:12:39 <bhill2> francois: also, how people do this in practice, we have two different files supposed to be the same, they will get out of sync
00:12:58 <bhill2> ... may not notice their fallback doesn't really work
00:14:32 <bhill2> johnwilander: UCBrowser is getting really big, is it webkit / blink based?
00:15:20 <JeffH> https://en.wikipedia.org/wiki/UC_Browser
00:18:16 <bhill2> deian: scariest thing is that versions may diverge
00:19:35 <rbarnes> rbarnes has joined #webappsec
00:22:22 <bhill2> bhill2: page weight of hashes is a concern given the number of JS files in Facebook
00:22:37 <bhill2> dev: we share that concern, maybe addressing signature support is a better first step
00:23:39 <bhill2> dev: so for module management, and dynamic includes, may need the full list
00:24:37 <bhill2> johnwilander: who would issue certificates
00:25:15 <bhill2> rbarnes: it's your own page, just do a public key, no certificate needed
00:25:28 <bhill2> ... we did something similar for content going into about: content
00:25:48 <bhill2> ... we don't have any way to declare which public key, we just require that everything that arrives is signed with a particular public key
00:26:09 <bhill2> ... defined with martin thompson's signature header:
00:26:25 <bhill2> https://tools.ietf.org/html/draft-thomson-http-content-signature
00:26:43 <bhill2> dev: this is way easier and cleaner
00:27:38 <bhill2> jww: is there merkle tree dovetailing here?
00:27:42 <bhill2> johnwilander: is there replay protection?
00:28:21 <bhill2> ... if there is a vulnerable version with a valid signature
00:28:25 <bhill2> francois: you change the key?
00:28:51 <bhill2> dev: for sites with so much javascript there is a pipeline that makes this trivial
00:29:05 <bhill2> jww: content hashes will still be the easiest for most sites
00:30:20 <bhill2> rbarnes: this means CDN can substitute any file signed (with a vulnerability)
00:30:36 <bhill2> bhill2: so like Artur's earlier statement about issues with CSP and whitelisting for large sets of JS
00:32:49 <bhill2> bhill2: you could put metadata covered by the signature that is checked by a module loading system like require.js
00:33:32 <bhill2> bhill2: should this be coordinated with the new module system for JS on the web?
00:33:43 <bhill2> dev: at some time all this packaging work is irrelevant
00:33:51 <bhill2> ... so signatures are more valuable
00:34:56 <bhill2> bhill2: to prevent file substitution, should modules have standardized metadata that interacts with integrity/signature checks?
00:35:21 <bhill2> dev: attractiveness is not having to reinvent this stuff
00:35:31 <bhill2> francois: but its a very different use case
00:36:12 <bhill2> dev: Merkle?
00:36:28 <bhill2> rbarnes: the merkle proposal is just straight hash, no signatures
00:37:05 <bhill2> dev: merkle lets you stream it in verified chunks
00:37:47 <bhill2> jww: is it better for anything we do today?
00:38:01 <bhill2> dev: for downloads
00:38:27 <bhill2> johnwilander: my immediate thought was: is this going to mirror what we consider active content?
00:38:43 <tanvi> tanvi has joined #webappsec
00:39:26 <JeffH> https://www.ietf.org/proceedings/95/slides/slides-95-httpbis-0.pdf -- Thiomson's preso from IETF-95 on MICE
00:39:33 <bhill2> bhill2: do scripts start to parse before integrity is verified?
00:39:39 <freddyb> JeffH: thx
00:40:05 <freddyb> s/JeffH: thx/thx, JeffH/
00:40:09 <JeffH> https://martinthomson.github.io/http-mice/
00:40:26 <bhill2> bhill2: would streaming help webasm?
00:41:59 <bhill2> dev: is there browser interest in mice?
00:42:04 <bhill2> freddyb: too early to tell
00:42:17 <bhill2> francois: not useful for script/style, only if we do other content types
00:42:20 <bhill2> dev: so for download
00:42:45 <bhill2> dev: dropbox can't do it without signatures, too
00:42:51 <bhill2> jww: so we should keep that on the table
00:44:39 <bhill2> bhill2: signature sounds more like a csp directive than sri as it currently looks
00:44:47 <bhill2> dev: could be that, make policy very much smpler
00:45:41 <bhill2> johnwilander: also would make your page not need to change
00:45:49 <bhill2> deian: how often would you need to revoke your keys?
00:45:54 <bhill2> dev: just do it every day?
00:46:29 <bhill2> ... have multiple keys to cover a window of validity
00:48:06 <wseltzer> rrsagent, draft minutes
00:48:06 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
00:48:14 <wseltzer> [adjourned]
00:48:15 <wseltzer> rrsagent, draft minutes
00:48:15 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
00:48:35 <wseltzer> present+ MattN
00:48:38 <wseltzer> rrsagent, draft minutes
00:48:38 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
00:49:04 <wseltzer> present+ Mike_West, Wendy_Seltzer
00:49:05 <wseltzer> rrsagent, draft minutes
00:49:05 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer
00:49:39 <wseltzer> i|if I'm example.com|scribenick: bhill2
00:49:40 <wseltzer> rrsagent, draft minutes
00:49:40 <RRSAgent> I have made the request to generate http://www.w3.org/2016/05/17-webappsec-minutes.html wseltzer