00:01:01 rrsagent, make minutes 00:01:01 I have made the request to generate http://www.w3.org/2014/10/28-webappsec-minutes.html bhill2 00:01:06 rrsagent, set logs public-visible 00:01:15 -mkwst 00:01:20 - +1.408.988.aaaa 00:01:22 Team_(webappsec)22:17Z has ended 00:01:22 Attendees were +1.408.988.aaaa, mkwst, +1.425.830.aabb, davidross 00:01:27 [adjourned] 00:26:12 gludi|2 has left #webappsec 00:51:24 deian has joined #webappsec 01:08:15 npdoty has joined #webappsec 01:20:58 puhley has joined #webappsec 03:41:49 bhill2 has joined #webappsec 04:50:48 bhill2 has joined #webappsec 05:14:36 npdoty has joined #webappsec 05:33:02 bhill2 has joined #webappsec 07:41:34 anssik has joined #webappsec 14:15:07 RRSAgent has joined #webappsec 14:15:07 logging to http://www.w3.org/2014/10/28-webappsec-irc 14:15:09 RRSAgent, make logs world 14:15:09 Zakim has joined #webappsec 14:15:11 Zakim, this will be WASWG 14:15:11 I do not see a conference matching that name scheduled within the next hour, trackbot 14:15:12 Meeting: Web Application Security Working Group Teleconference 14:15:12 Date: 28 October 2014 14:15:17 rrsagent, this meeting spans midnight 15:17:46 fjh has joined #webappsec 15:29:30 fjh has joined #webappsec 15:36:13 bhill2 has joined #webappsec 15:41:12 bhill2 has joined #webappsec 15:41:50 zakim, this will be WASWG 15:41:50 ok, wseltzer; I see SEC_WASWG()11:30AM scheduled to start 11 minutes ago 15:42:07 bhill2 has joined #webappsec 15:46:56 gludi|2 has joined #webappsec 15:51:46 gludi|3 has joined #webappsec 15:54:32 SEC_WASWG()11:30AM has now started 15:54:40 + +1.415.596.aaaa 16:00:53 glenn has joined #webappsec 16:01:12 Kevin_Hill has joined #webappsec 16:01:31 +tanvi 16:04:30 colin has joined #webappsec 16:04:57 + +1.408.988.aabb 16:05:01 keiji_ has joined #webappsec 16:05:32 anssik has joined #webappsec 16:05:36 Meeting: WebAppSec WG TPAC 2014 F2F Day 2 16:05:42 Chairs: bhill2, dveditz 16:05:51 Agenda: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit 16:05:54 bhill2 has changed the topic to: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit 16:06:12 zakim, who is here? 16:06:12 On the phone I see +1.415.596.aaaa, tanvi, +1.408.988.aabb 16:06:13 On IRC I see anssik, keiji_, colin, Kevin_Hill, glenn, gludi|2, bhill2, fjh, Zakim, RRSAgent, rigo, schuki, Josh_Soref, tobie, timeless, mkwst___, freddyb, renoirb, terri, 16:06:13 ... wseltzer, trackbot 16:06:36 zakim, aaaa is puhley 16:06:36 +puhley; got it 16:06:40 Zefa has joined #webappsec 16:06:46 zakim aabb is [SalonB] 16:06:52 zakim, aabb is [SalonB] 16:06:54 +[SalonB]; got it 16:06:55 JeffH has joined #webappsec 16:07:02 ckerschb has joined #webappsec 16:07:22 zakim, [SalonB] has bhill2 16:07:22 +bhill2; got it 16:07:34 deian has joined #webappsec 16:08:21 nvdbleek has joined #webappsec 16:09:01 zakim, [SalonB] has Kevin_Hill 16:09:01 +Kevin_Hill; got it 16:09:12 scribenick:rigo 16:09:30 BH: scheduled until 16:15 16:09:38 Zefa has joined #webappsec 16:09:46 Introduction: 16:10:46 -> see minutes from 27 Oct 16:11:21 dwalp has joined #webappsec 16:11:45 zakim, [SalonB] has ckerschb 16:11:45 +ckerschb; got it 16:12:00 zakim, [SalonB] has dwalp 16:12:00 +dwalp; got it 16:12:07 Zakim, [SalonB] has deian 16:12:09 +deian; got it 16:12:36 BH: Presentation of the Agenda 16:12:56 Ein weiterer Ort an der Grenze zwischen Niedersachsen und Sachsen-Anhalt. 1958 wurde auf der Westseite in Zicherie ein Stein mit der Aufschrift "Deutschland ist unteilbar" an der innerdeutschen Grenze aufgestellt. Er steht heute als Gedenkstein in unmittelbarer Nähe zum Ortsschild des Nachbarortes Böckwitz. 16:13:03 lef has joined #webappsec 16:13:20 Charles_Engelke has joined #webappsec 16:13:59 Agenda: https://docs.google.com/document/d/1k6juq6E-mzlNzVr-tHhrh9mEh-d51Uf8wfgfo1I1yZQ/edit 16:14:13 rrsagent, set log public 16:14:22 rrsagent, please draft minutes 16:14:22 I have made the request to generate http://www.w3.org/2014/10/28-webappsec-minutes.html rigo 16:15:08 regrets, Mike West 16:15:23 regrets+ Mike_West 16:15:32 dveditz has joined #webappsec 16:15:42 survey results for rechartering 16:16:30 http://lists.w3.org/Archives/Public/public-webappsec/2014Oct/att-0159/SurveyMonkey_Analyze_-_WebAppSec_2014_Charter.pdf 16:17:23 Credential management API, almost consensus, two people volunteered to work on it 16:17:59 BH: give more structure so that browsers can make more out of password feels 16:18:07 s/feels/fields/ 16:18:46 http://mikewest.github.io/credentialmanagement/spec/ 16:23:03 bhill2 has joined #webappsec 16:25:18 ckerschb has joined #webappsec 16:27:38 -tanvi 16:33:36 bhill2 has joined #webappsec 16:36:25 nvdbleek has joined #webappsec 16:37:43 we are back... 16:38:26 colin has joined #webappsec 16:38:38 we're back? 16:39:35 we're back 16:40:05 tanvi has joined #webappsec 16:40:18 jystewart has joined #webappsec 16:41:18 Zefa has joined #webappsec 16:42:01 TOPIC: rechartering topics 16:42:07 TOPIC: Credential Management API 16:42:12 general agreement 16:42:33 JeffH has concerns about scope, potential impact of other efforts, e.g. FIDO, or related work 16:42:37 miterho has joined #webappsec 16:42:41 ... coming from WebCrypto workshop to replace passwords 16:42:47 he will respond on list 16:43:26 deian has joined #webappsec 16:43:34 present+miterho Mikko Terho Huawei Tecnlogies 16:44:00 CharlesEngelke has joined #webappsec 16:44:01 present+ Brad_Hill Jeff_Hodges Christoph_Kerschbaumer Melinda_Shore 16:44:14 npdoty has joined #webappsec 16:44:56 present+ Deian_Stefan Daniel_Veditz 16:45:26 present+ Tanvi_Vyas 16:45:54 dveditz: should work on credentials to help with passwords 16:46:29 BH: client side is not compromising really data, but protecting server side data 16:46:45 present+ Terri_Oda 16:47:12 tanvi: write only passwords (Loopin) iframe all of login forms and scrape them to see if secure 16:47:27 ... http-page, write only type passwords 16:47:42 dveditz: argued against it for 10 years 16:47:49 s/Loopin/Lupin 16:48:03 BH: reasonable agreement to work on credentials 16:48:17 I argued against password auto-fill without any user interaction 16:48:24 BH: any objections 16:48:29 => silence 16:48:47 BH: write only form elements will not be done 16:48:49 dwalp has joined #webappsec 16:48:53 (because then an attacker can mass-harvest passwords potentially) 16:49:09 Automated Password Extraction Attack on Modern Password Managers, http://arxiv.org/pdf/1309.1416v1.pdf 16:49:34 ... no-sniff, header X-content: no-sniff. Content sniffing rules that A.Barth worked on in IETF habe been picked up by WhatWG 16:50:09 ... defined in mimesniff WhatWG, seems like already done in WhatWG 16:50:20 ... no reason to duplicate 16:50:31 dveditz: everyone is using that, so why bother 16:50:53 tanvi: a more recent paper on password manaagers: https://www.usenix.org/conference/usenixsecurity14/technical-sessions/presentation/silver 16:51:31 deian: thanks! 16:52:23 dveditz: mainly documenting what IE (invented) and chrome is doing already 16:52:27 BH: agree 16:52:55 BH: unanimous agreement to work on CSP next generation 16:53:14 ... dom API, service workers, explicit about fetch etc. 16:53:22 ... no objections in the room 16:53:46 BH: suborigins (joe will talk about it later) 16:54:05 BH: sandboxed cross origin workers, two votes against 16:55:03 JeffH has joined #webappsec 16:55:06 ... concerned about breaking google analytics and FB like button. But also vector for large scale attack. manipulating jquery e.g. 16:55:30 ... we are addressing with subresource integrity, but also dynamic scripts 16:56:07 ... difficult to apply subresource integrity to that. Interested in ways to secure here 16:56:38 ... post message channel, well known interface. Much smaller attack surface. Web components is not taking that approach 16:57:15 ... iframes are heavyweight. If include 30 of those scripts, it becomes to heavy 16:57:44 ... perhaps create a worker, static interface that is identified with subresrouce integ. and some dynamic part 16:58:40 lef has joined #webappsec 16:59:00 RW: perhaps looking into provenance 16:59:18 dveditz: interested in this, but not if it is duplicated elsewhere 16:59:44 ... the thing I read tried to get around the iframe weight 17:00:04 ... ECMA 6 or 7 will come up with containers 17:00:34 deian: we are doing something similar, container, context X, then extension components within this worker 17:00:49 ... little bit more powerful than just ecmascript 17:01:15 BH: put in charter, script sandboxing 17:02:38 RW: STREWS is planning to work on sandboxing, so would be good to have it in the charter 17:02:51 BH: no objection, seems to be reasonable to work on 17:03:30 bhill2: WebCrypto Workshop, Virginie will summarize on Thursday. Some of it could end up here 17:04:05 ... concerns about bringing it into WebAppSec because of the more controversial IPR around hardware 17:04:22 ... don't want to derail CSP 17:04:42 ... can follow on public-web-security for chartering 17:06:08 RW: good idea to have only a strong dependency 17:06:39 bhill2: yes, whether in WEb Crypto or new group, will insist on dependency 17:07:01 bhill2: summarizing the points for the charter... (too fast for scribe) 17:07:49 Topic: Presentation by Deian on Confinement with Origin Web Labels (COWL) 17:08:03 RRSAgent, please draft minutes 17:08:03 I have made the request to generate http://www.w3.org/2014/10/28-webappsec-minutes.html rigo 17:08:26 TOPIC: Deian Stefan introducing COWL 17:08:29 -puhley 17:08:35 slides will be sent out later 17:13:16 puhley has joined #webappsec 17:13:19 puhley has left #webappsec 17:13:23 puhley has joined #webappsec 17:25:29 Current status of COWL: portin to latest FF & Chromium 17:26:20 nvdbleek has joined #webappsec 17:27:15 deian: how to do enforcement? CSP allows to control where context can disseminate data 17:29:54 ISSUE-69? 17:29:54 ISSUE-69 -- Consider directives to manage postMessage and external navigation of iframes -- raised 17:29:54 http://www.w3.org/2011/webappsec/track/issues/69 17:30:25 deian: COWL has intersection with issue 69 17:30:58 ... creates a kind of reverse sandbox 17:31:28 ... http://cowl.ws/ 17:32:10 question: why not add this to the javascript engine for label propagation 17:32:26 ckerschb: label propagation, how to prevent an attacker to inject their own labels 17:33:19 bhill2: what about cover channels, side channels? 17:33:42 deian: once you enable mode, you get post message 17:33:57 .... it is an opt-in system, doesn't break existing web 17:33:58 deian: difficult to use by programmers, don't need to label everything, get unlimited labeled blobs as needed (in response to last question) 17:34:39 bhill2: what is it look like for sites distributing widgets, third party to include your resource, make it as easy as possible 17:34:50 deian: self protection? 17:35:26 bhill2: yes, like button ... the ability to copy-paste a snip of javascript into pages 17:36:17 deian: this should be the case, the Lworkers does that. fundamental principle is data source is trusted. 17:36:28 ... widget can always send to parent 17:37:13 bhill2: ship same app ot browser 8 (not support) and 9 (that supports)? 17:37:27 deian: you give up security as you can not know whether it works 17:37:56 bhill2: so have to understand the analytical message and react upon it 17:38:16 server knows if browser supports cowl 17:38:23 deian: yes, prot should tell whether supports COWL 17:39:16 MS: dozens of checks? 17:39:25 deian: dozens, being able to ?? 17:39:38 ... implemented a few larger scales 17:39:49 Zakim, who is here? 17:39:49 On the phone I see [SalonB] 17:39:50 hi freddy, we are just doing some questions for COWL and will start shortly 17:39:50 [SalonB] has deian 17:39:50 On IRC I see nvdbleek, puhley, lef, JeffH, dwalp, npdoty, CharlesEngelke, deian, miterho, Zefa, jystewart, tanvi, colin, bhill2, ckerschb, dveditz, anssik, glenn, gludi|2, fjh, 17:39:50 ... Zakim, RRSAgent, rigo, schuki, Josh_Soref, tobie, timeless, mkwst___, freddyb, renoirb, terri, wseltzer, trackbot 17:40:15 bhill2: is this interesting stuff to consider? 17:40:23 ... some sense of interest? 17:40:52 rigo: have you considered as a use case offline workers? 17:41:04 ... you don't want e.g. firefox os phone to leak your address book only because it can 17:41:18 ... in this case the labeling has the function of protecting user-centric info 17:41:33 ... but how to your provide an interface for the user to manage privileges 17:41:38 ... e.g. to prevent an app from phoning home 17:41:50 +??P3 17:41:57 Zakim, I am ??P3 17:41:57 +freddyb; got it 17:42:00 deian: if you as a user are using e.g. facebook, you're specifying a policy about who can view your information 17:42:11 deian: thought about phones, but were mainly concentrating on server side 17:42:32 ... we can label that information through app UI interactions 17:43:10 in context of offline applications, lables are easier 17:43:39 gludi|2 has joined #webappsec 17:44:01 rigo: if I am an attacker, I would say if I temporarily disallow phoning home, can I hide the information I want to leak and wait until the restriction is over 17:44:37 deian: if you store things, the mandatory label persists, so it is re-applied when it is read again 17:44:58 rigo: so there are additional requirements on, e.g. local storage 17:45:35 markw has joined #webappsec 17:46:17 rigo: have you thought about abusing restrictions? block everything X? 17:46:34 deian: whoever you send data to, they have to decide to unlabel it themselves. 17:46:46 ... labels can only be raised by the context, not by another context 17:47:22 rigo: can I create e.g. DRM to e.g. prevent copy/paste? 17:48:14 bhill2: very interesting discussion, first time we have seen it, have to bring it to the list 17:48:27 ... any strong objection to include it into the charter discussion 17:48:56 Dan: we had already lightweight isolation etc.. 17:49:26 bhill2: should we consider this under "lightweight sandboxing" have some more on the table, COWL would be added to the list 17:49:37 Melinda: yes, just add 17:49:57 JeffH: yes, but not DOM manipulation 17:50:25 bhill2: some agenda discussion; Suborigin proposal 17:50:49 TOPIC: Joel Weinberger introducing SubOrigins proposal 17:51:03 jww: we have the origin security primitive in the browser 17:51:12 ... sometimes you can't create a new origin just to make something untrusted 17:51:19 gludi|2 has joined #webappsec 17:51:19 JW: often different things into the same origin, but need different levels of security 17:51:21 ... would be great to be able to split things into smaller origin pieces 17:51:35 ... e.g. google.com is search, google.com/maps is a very different application 17:51:39 npdoty has joined #webappsec 17:51:42 ... that is on the same origin for historical and other reasons 17:51:47 ... but has different security properties, etc. 17:51:58 ... would be great to be able to treat them as different principals 17:52:10 ... proposal allows creation of arbitrary namespaces for applications 17:52:43 freddy - better? 17:52:57 bhill2: much better. thanks! 17:53:06 also thanks to jww for repeating! 17:54:48 devd: dropbox would be very excited to use this 17:55:12 jww: current proposal is a csp header with a tag for what suborigin you want to enter 17:55:49 ... gets represented as an addendum to the scheme 17:56:12 ... e.g. plugins have own way to deal with origins, would be nice to not have to rewrite that by putting into current origin token architecture 17:57:45 ... this is basically named sandboxes 17:59:55 I wonder if there's overlap with scopes (existing in serviceworkers, manifests) and cookie path limitations ;) 18:00:44 [start again in 10 min] 18:02:33 fjh has joined #webappsec 18:02:42 npdoty has joined #webappsec 18:04:35 nvdbleek has joined #webappsec 18:09:58 nvdbleek3 has joined #webappsec 18:10:10 bhill2 has joined #webappsec 18:11:50 TOPIC: Subresource Integrity 18:12:00 gludi|2 has joined #webappsec 18:12:25 deian has joined #webappsec 18:12:42 Zefa has joined #webappsec 18:12:56 [resuming] 18:13:10 gludi|2 has joined #webappsec 18:13:10 http://w3c.github.io/webappsec/specs/subresourceintegrity/ 18:14:11 bhill2: want to check in SRI, since there are news. what's going on? and let's look at 18:14:38 devd chrome has an implementation, we'll take a look. most people seem happy with the spec. same goes with the community 18:14:55 devd if anything we should be doing more 18:15:02 q+ 18:15:05 joel big question: https and http. should it apply to http? 18:15:35 dev has joined #webappsec 18:15:41 two half: should SRI run on non-https pages. can you even make an integrity attribute? can you have integrity attribute to http content? 18:16:46 dveditz: not sure why you wouldn't want to do http. we don't want to relax MIX; as integrity guarantee why not allow it? 18:16:59 gludi|2 has joined #webappsec 18:17:16 joel: integrity should not be allowed to run on insecure origins; i think we should ignore the integrity attribute since it's meaningless and attackers can modify 18:17:23 tanvi: not serverside attacks, only MITM 18:17:31 it's only meaningless in the face of _active_ attackers, not passive attackers (i.e. reading) 18:17:41 rrsagent, draft minutes 18:17:41 I have made the request to generate http://www.w3.org/2014/10/28-webappsec-minutes.html wseltzer 18:18:20 i/Joel Weinberger introducing SubOrigins proposal/scribenick: bhill2 18:18:25 I agree with what I think I heard dev saying (that it still protects the compromised CDN case on plain http) 18:18:31 dveditz: i know we're trying to encourage tls, but it seems mean to not include http 18:18:34 i/[resuming]/scribenick: deian 18:18:40 gludi|2 has joined #webappsec 18:18:41 rrsagent, draft minutes 18:18:41 I have made the request to generate http://www.w3.org/2014/10/28-webappsec-minutes.html wseltzer 18:19:08 gludi|2 has joined #webappsec 18:19:17 joel from our perspective it is a little questionable on how you present this to developers. dveditz it's same as http content, so most of the time you get what you expect. 18:19:40 joel SRI gives you integrity, but it's not clearly useful since attacker can modify it. 18:20:02 dveditz: if things keeps getting breaking because of no https, then devs will lean to use tls 18:20:22 joel: if you have a MITM attack then you can just serve content with proper integrity attribute 18:20:45 should webcrypto occur on http? 18:20:59 can't do it in any meaningful way for http 18:21:39 bhill2: load resouce but not check integrity? 18:21:51 khoya has joined #webappsec 18:22:00 q+ 18:22:11 ack freddyb 18:22:15 dveditz: two choices: not load resources OR spit out console message and say wheneter or not you checked the integrity 18:22:39 freddyb: not sure i got everything, but as far as i understand: heavily agree on MIX: should not relax this 18:23:09 on the other hand, afaiu not sure if we'll reach consensus on http vs https, maybe take offline 18:23:37 original question: i think it's a good idea to go forward with scripts only for now. seems like the most meaningful way to go forwar 18:23:42 ack wseltzer 18:23:52 joel: i would suggest style as well, but script is definitely the priority 18:23:53 https://www.w3.org/wiki/TPAC2014/SessionIdeas#Trust_and_Permissions_in_the_Open_Web_Platform 18:24:43 wseltzer: dave ragget suggested (on truste & permission) and I'm looking to collect from dif places to address similar problems in similar ways. so if you're seeing this in other places, let me know. and if others (chris palmer started a thread) are itnerested please bring them in the discussion 18:25:10 npdoty has joined #webappsec 18:25:20 bhill2: we have a subset that is not controverisal that people want to use now. there is the other subset that is controvertial. should we prune out the latter? 18:25:47 ship the first (level 1) and work on the second at a different pace 18:26:09 joel: seems like a good idea, given that even at google we can't reach consensus on the controvertial 18:26:13 glenn has joined #webappsec 18:26:24 bhill2: no relaxing of MIX warning. script & maybe style 18:26:36 what about object source? 18:26:46 devd not sure what the use for object src is? 18:26:53 bhill2: same as script 18:27:14 npdoty_ has joined #webappsec 18:27:22 devd: concern for compatability. too many things that happen with object to deal with it now 18:27:42 downloads? 18:27:50 dveditz: would love to do it, but in practice it's hard. devd: sites can use CSP to restrict objects for now 18:27:53 Tomoki has joined #webappsec 18:28:08 bhill2: what about downloads? 18:28:33 tor exist nodes backdooring exe files. lots of download sites. unfortunately this brings back the http vs. https issue 18:28:42 would be nice to apply integrity to it 18:29:00 not the same threat model since it's not part of the DOM, but the threat model is worse 18:29:25 devd: what's the mixed content story for downloads? 18:29:31 tanvi: we block http downloads 18:29:49 well, not exactly 18:29:50 tanvi: depends, e.g., if it's iframe we block, but if you navigate it's okay 18:30:00 tanvi: ^ does that capture ti? 18:30:15 yes :) 18:30:31 devd seems like a great case for using SRI for http. tanvi: download whole file and check integrity? 18:30:56 devd: browsers download then raname, we would check integrity before rename 18:31:11 joel: there were a bunch of issues that were raised wrt to this 18:31:58 joel: controvertial in chromium team, but encouraging http downloads since we have integrity may lead to less https 18:32:20 @@: what's the proposed experience when integrity fails? devd: same you get today: this may be malware 18:32:29 s/@@/mnot/ 18:32:43 but integrity is not authenticity. I'd hope we could argue that "good" websites would really want to strive towards both (and the latter is only viable through HTTPS?) 18:33:17 ..thinking that integrity wouldnt really discourage https 18:33:38 because this imposes on author to keep hashes up to date, this may result in many false positives. may lead to people switching browsers. bhill2 what about user copying link and pasting it into addr bar 18:34:03 joel: UAs can make it harder to copy URLs that have integrity attributes 18:34:10 already do this for javascript:// urls 18:34:21 bhill2: doesn't have to have the malware warning 18:34:39 joel: we sould adjust according to what we see in the wild [that is the false positives] 18:35:00 bhill2: how do we reduce the click throughs? can keep iterating on this 18:35:18 mnot: ssl configuration is one problem. this is an authoring problem and I wonder how this would work out 18:36:25 bhill2: even if page is maliciously modified, some users will get around it 18:36:43 tanvi: seems like MITM is a bigger threat. 18:37:03 dwalp has joined #webappsec 18:37:07 tanvi: in 1st version, what if we keep it ambigous about http? joel: certainly okay 18:37:27 rigo has joined #webappsec 18:37:43 tanvi: for downlaods, i see a reason to keep it to https only, but for js not so much since there are so many examples of people pulling content from http places 18:39:02 bhill2: the attacker cost to compromise jquery cdn is smaller than everybody on https. mnot: devs have to be careful when they use SRI, since e.g., flicker may change source e.g., due to bugs 18:39:07 tanvi: how do we handle versioning? 18:39:15 how should sites deal with changes? 18:39:46 joel: is SRI useful? devd: we can give multiple hash values. if file names remain constant you may supply current, old version of hashes 18:40:04 if filename has part of hash, this is a solvable problem 18:40:14 bigger question is to ask jquery about this kind of versioning problems 18:40:53 we can run experiments for a few months and see how things go. we don't rely on latest version of jquery, we rely on specific version, so hashes just gives you more 18:41:25 joel: try to load latest from cdn, but if it's not what you expect, but you can load from your site 18:42:11 deian: what about signatures? bhill2: shakes/has seisure 18:42:18 are we going to replace an integrity problem with a key-sharing problem? 18:42:28 ;) 18:42:39 ;) 18:42:49 problem with signatures is that it doesn't really change the threat model and adds lots of complexities 18:43:00 there is interest, now with webcrypto... 18:43:01 JeffH: +key management issues 18:43:14 tanvi: there is an xml signature proposal 18:43:21 s/tanvi/dveditz/ 18:44:04 mnot: we're interest in solving this and more general problem. though we talk about it at a transport layer where you have another identity. use case: im a bank, but don't trust cdn with everything (only with certain things) 18:44:19 bhill2 has joined #webappsec 18:44:37 (with SRI relying on CORS-enabled resources, one could do XMLHttpRequest to fetch, webcrypto to verify and blob URIs (=same origin) to load) 18:44:46 dveditz: lots of places where signatures are needed, but webappset is not the right place for this 18:45:41 jeffh: I'm imaging this useful/deployable with server side support. I have this web app, on the server side I check all the deps and compute the hashes. On the server side I can make sure that whatever I spit out to the client-side is correct 18:45:41 [another use case is the user has out-of-band assurance at one point in time, and wants to pin that] 18:46:10 (i'd like to talk about caching when we have a chance.) 18:47:35 mnot: link headers/manifest seems like an alternative approach ...; bhill2: we're probably going to split spec into 2 specs: content addressable vs. the less controversial; devd: we have objections to objects, joe wants styles (maybe not so bad), but anchors and downloads are uncontrovesrial 18:47:55 bhill2_ has joined #webappsec 18:48:01 billh2: it's worth trying (that's what we mean by uncontroversial), and see if it works/if people can put it to use 18:48:10 mnot: talk about or implement? 18:48:27 bhill2_: implement it enough and actually learn from how people use 18:48:43 bhill2_: we can speculate on how people use this, but i don't think we know until we put it out there and learn from data 18:49:07 JeffH: when you say object you mean ? dveditz and applet and embed tags; bhill2_ stuff covered by object-src 18:49:10 in csp 18:49:17 mnt: is it worth to talk about this in ters of fetch? 18:49:28 dveditz: spec is written in terms of fetch 18:50:21 bhill2_: mostly specified as monkey patch to fetch 18:51:05 bhill2_: lots of good reasons to specify in separate document. may have mutual dependencies. certainly we're going to need to figure out hot to normally reference fetch 18:51:54 bhill2_: download is still controversial in terms of how it should work and how we should do it? dveditz controvertial in how you present it to people. devd browser vendors should decide this 18:52:30 joel: it is controversial in chrome to do http downloads. dveditz because of the http part from https? should we do downloads? joe: yes 18:52:52 devd its far more like that you have a download from http url on an https page 18:53:38 mnot: problem is that people publishing link and actual download are different people 18:54:31 what should we warn on? how will people react?; tanvi: if we put leave it ambigous then that would solve the problem for chrome too 18:54:48 jeol: we would be happier if everybody did secure downloads, but sure 18:55:01 devd: if chrome and ff differ on this part it's okay according to spec 18:55:38 bhill2_: how much will the cut simplify the spec 18:55:45 joel: it cuts out all the cache stuff, that's huge 18:55:52 we did not talk about reporting! 18:56:11 happy to leave it out for now, just remembered. 18:56:13 is there reporting in the spec? 18:56:18 I missed that 18:56:49 reporting is important to alert websites about third party libraries that have changed withotu their knowledge 18:57:07 dveditz: there is. http://www.w3.org/TR/SRI/#handling-integrity-violations-1 18:57:24 tanvi: in theory, you could get it from logs through the fallback mechanism 18:57:35 freddyb: what section? 18:58:06 dveditz: 4th paragraph this 3.5.4: "MUST repor a violation" 18:58:08 report* 18:58:17 devd: how painful the non-cononical src would be to implement? 18:58:23 3.5.2 in the editor's draft 18:58:28 noncanonical-src attribute 18:58:41 dveditz: don't really understand why we would use the noncononical-src 18:59:06 if the source would change the you would fallback on your slow secure server 18:59:15 said tanvi 18:59:33 devd: simple enough attribute that we should do it 18:59:54 dveditz: I will ask; joe: I think it's complicated, but if we see enough value we should do it 19:00:03 +q 19:00:11 ack freddyb 19:02:00 i.e., if (typeof jQuery === "undefined") { // create script node + same-origin jquery URL and add to DOM } 19:02:03 freddby: was wondering if you really want an authenticate same-origin version of the reource. what about: if jquery is not defined, the use shim to load from secure source? not saying we shouldn't do it in the spec; joe: interesting point: should we be defining what it means to fallback or is that application specific. tanvi: that makes it harder to implement apps 19:02:06 glenn has joined #webappsec 19:02:12 if it's cross-origin content: I can't take hash 19:03:07 tanvi: if we take noncon.. and ask devs to write own code to handle fallback, the adoption would be much harder 19:03:29 devd: i think devs already do this since they don't want to rely on jquery cdn to stay up 19:04:48 joe: if we don't offer it then we'll never know. devd: should this be in level 1 spec or level 2 spec. joe: I don't think it's controv, but it may be hard to implement 19:05:16 SRI requires cors-enabled though, which means you _can_ compute a hash manually. 19:05:20 dveditz: if you load nonc.. do you still check hash? bhill2_: no, it's a fallback & trusted 19:06:12 nvdbleek has joined #webappsec 19:06:12 dveditz: I don't know it sites will use this; joel: proposal: rename src and backup-src 19:06:49 dveditz: src has to be what normally gets loaded 19:07:05 I too dislike "noncanonical-src" as an attribute name. "src" & "fallback" seems more intuitive. 19:07:26 colin has left #webappsec 19:08:07 joe: will update spec to use better names; tanvi: does fallback perform integrity check? devd: no, since the fallback should be for something that definitely works 19:08:10 [have we ever done a privacy review of the various reporting options?] 19:08:21 q+ 19:08:55 dveditz: from the text it seems like report doesn't block so we should rename to report-only. 19:09:02 nvdbleek3 has joined #webappsec 19:09:07 devd: spec needs editing 19:10:10 tanvi: how should reporting work? dveditz: piggy back on csp. devd: could trigger JS error 19:11:36 bhill2_: to wseltzer's question: we had external people look at it and it doesn't leak any addition info. dveditz there was an issue with reporting and redirects, but we fixed the spec; joe: it's been ad-hoc 19:11:54 wseltzer: bookmark could hook on to reporting to ignore reports 19:12:19 dveditz: need to make sure that sites don't learn about what add-on's you have instaleld 19:12:38 tanvi: what about caching? if same resource is fetched from two sites. joes &devd: we're going to punt to level 2 19:12:41 s/ignore/drop/ 19:12:48 s/bookmark/bookmarklets/ 19:12:55 wseltzer: thanks :) 19:13:10 brendaneich has joined #webappsec 19:14:26 bhill2_: to summarize 2 sides: this is not making anything worse, it's strictly making things better. dveditz if we load things by hash then we could have cache poisoning attacks and attribute attack to wrong person 19:14:41 devd this is a big can of works, let's just focus on level 1 and deal with rest later 19:15:30 bhill2: if you identify exact content. where it comes from doesn't matter. joe: there were lots of questions about caching headers, which I think is more controversial. 19:16:01 consnus on the pruning and working on the less controversial first 19:18:45 bhill2: there is an proposal to expose dns info to the browser. might be useful to have this group of people to look at this and evaluate what could possibly go wrong & tell them not to do certain things even if we don't consider it at webappsec; wseltzer this is from versign who want so to be involved. we should work with them and see what can be improved 19:19:04 thanks for taking notes, deian 19:19:05 rrsagent, make minutes 19:19:05 I have made the request to generate http://www.w3.org/2014/10/28-webappsec-minutes.html wseltzer 19:19:15 rrsagent, make logs public 19:19:20 bhill2 has joined #webappsec 19:19:23 [lunch break] 19:19:29 it helped a great deal in syncing the audible bits into something meaningful \o/ 19:19:47 freddyb: glad it helped, sorry for missing things :) 19:19:57 this raised hands here \o/ are unrelated to your lunch/afternoon plans 19:21:33 enjoy lunch, people! 19:21:53 -freddyb 19:22:00 [now really adjourned] 19:22:04 zakim, end call 19:22:04 I don't understand 'end call', wseltzer 19:22:06 bhill2_ has joined #webappsec 19:22:16 -[SalonB] 19:22:18 SEC_WASWG()11:30AM has ended 19:22:18 Attendees were +1.415.596.aaaa, tanvi, +1.408.988.aabb, puhley, bhill2, Kevin_Hill, ckerschb, dwalp, deian, freddyb 19:37:28 Zefa has joined #webappsec 19:44:33 glenn has joined #webappsec 19:57:41 glenn has joined #webappsec 19:59:37 Zefa has joined #webappsec 20:15:16 Zefa has joined #webappsec 20:16:05 puhley has joined #webappsec 20:20:50 brendaneich has joined #webappsec 20:21:19 npdoty has joined #webappsec 20:22:45 bhill2 has joined #webappsec 20:24:41 puhley has joined #webappsec 20:25:51 rrsagent, draft minutes 20:25:51 I have made the request to generate http://www.w3.org/2014/10/28-webappsec-minutes.html bhill2 20:32:15 ckerschb has joined #webappsec 20:33:03 tanvi has joined #webappsec 20:33:41 nvdbleek has joined #webappsec