WEBSEC WG Monday, July 25, 2011, 1300-1500, Room 202 Chairs: Tobias Gondrom , Alexey Melnikov https://datatracker.ietf.org/wg/websec/charter/ Audio Archive: http://www.ietf.org/audio/ietf81/ietf81-202-20110725-1256-pm.mp3 Jabber: websec@jabber.ietf.org attendees: 90 Minutes based on notes taken by Yoav Nir 1. Administrativia, Blue sheets - Tobias - start 13:06 - no further additions or modifications to agenda 2. WG Status, draft status - Tobias - Origin (includes Principles of the Same-Origin Policy) draft-ietf-websec-origin-02 now includes the principles of origin into the main draft, and also feedback from mailing list (3 items remaining). WGLC until Aug-15. Further revieweers? Who has read the draft? 10 people. Any more who intend to? 3 hold up their hand. - Mime-Sniffing draft-ietf-websec-mime-sniff-03. Not much review, conflict with draft-manister-web-info-02. Not much progress. How many have read? Around 8. Anyone who intends to review? 1-2. Should probably defer to next meeting especially as the author is not here. 3. HSTS: draft-ietf-websec-strict-transport-sec-01 - Jeff Hodges - 13:14 draft-ietf-websec-strict-transport-sec-01 from 14-Mar -02 in progress. Out next week of this. Implemented in FF and Chrome. At least one more coming. 80+ web apps issue STS policy www.shodanhq.com All formally open issues are detail-level spec clarifications. 12 open tickets: 3 are closely related Tickets 2,3,12: HTTPbis dependency of effective request URI. Jeff has decided to copy needed stuff from HTTPbis and not rely on it. Otherwise HTTPbis may delay us. So now we depend only on 2616 (all that in -02) Other detail-level clarifications. #11: user recourse - move to implementation advice. Other items: Adam Langley (chrome) noted on DANE list that we can't hard fail (with bad DANE signatures) So what about LockEV, LockFoo: work on them later (possibly in a separate spec)? Next Steps: Do we go to -02 with present spec, or first resolve LockFoo? Note: HSTS is extensible. Questions? Alexey: any disadvantages to moving LockFoo stuff to a future document? Jeff: see next presso 4. draft-hodges-websec-framework-reqs-00 - Jeff Hodges - 13:26 submitted 7-Mar. Brand new. A broad-brush sketch overall web application problem space. Leverages CSP discussion from W3C public web security list. No comments so far. Adam Langley noted on DANE ("a browser's myopic view") that they're not hard-failing If browsers are only willing to strictly enforce policies in HTTP (such as HSTS) what about LockFoo? Tobias: doesn't this have a higher overlap with DANE? Jeff: The DNSSEC last mile problem prevents browser vendors from paying attention to DANE. They want HTTP-conveyed policy despite Trust on First Use (TOFU). Yngve: pre-configured list - how do you add anything to that? JeffH: ad-hoc - opens door to DoS (tell Chrome that cnn.com is HSTS - it doesn't have SSL) - this is experimental still. Yngve: need something reliable and one-stop. IANA registry? JeffH: OK Tobias: (no hat) - the list is just an add-on. The primary method is via http(s), but the list just prevents the need for TOFU JeffH: yes Tobias (hat on) - should take to the list whether we want a standard mechanism for the list JeffH: yes There are at least 5 other web app spec efforts that are now inventing HTTP headers for policy conveyance. "they're sprouting up all over the place". Maybe we need a general-purpose framework for headers carrying policy? To-Do: revise I-D. Need review to help determine if all aspects of problem space are represented. point to other http-conveyed policies Tobias: do we need more review from WebAppSec ? JeffH: Yes, it's input for both groups, but it's very rough, and we don't want them to feel like they're wasting their time. Tobias: timeframe? JeffH: Late August 5. W3C Web App Sec briefing (CSP, reqs, ...) - Thomas Roessler - start 13:41 Chartering progress. Have draft charter, proposed co-chairs: EKR+Hill. Deliverables: CORS & UMP: policy expression for cross-origin XMLHttpRequest CSP: content restrictions for a web resource. Secure Cross-Domain Framing Cross-Origin Authorizations: CORS,UMP: you can access my data if your origin is foo.com X-Frame=Options: you can frame me if your origin is bar.com or same Origin Timing-allow-origin: you can access timing information about me if you're from baz.com. mitigates timing attacks CSP Major need for coordinations between IETF and W3C W3C WG should be set up in early September Questions: Tobias: timing attacks? How are they prevented. ??: API for timing information about access to resources. By default it's only same-origin. Want to get it to cross-origin. 6. Frame-Options - Tobias Gondrom - 13:51 X-Frame-Options widely deployed. Helps prevent XSS, CSRF First draft result from Beijing and OWASP. Wanted to get to standard and drop the "X-" prefix in the header field name. HTTP header: "deny" (do not display in a frame) and "sameorigin" (can be framed if the top frame from same origin). Now adding "allow-from:" and a list of acceptable framers. Issues: allowed framing: top level, or whole chain? origin: should be harmonized with the origin draft? (Currently the behavior is different) allow-from: one or more origins - prefer only 1 to keep header small behavior in case of a fail interdependencies with CSP (frame-ancestor) - W3C may take it out of CSP Other approaches: CSP From-origin draft - about half page now. Adam Barth: problems with caches Do we want this in WebSec? Need volunteers to review. Existing reviews will lead to a new version. Discussion & Questions: JeffH: we need to document the current X-Frame-Options in RFC form as it's implemented in browsers. Do they include allow-from: ? The blog post says yes, but this draft goes further. We should nail down present practice. Later talk about evolving this. Tobias: ostensibly in wide use, but not sure it's consistent. Would like to unify this JeffH: there is precedent of taking some vendor's practice to INFORMATIONAL. Tobias: if we nail it down as it is, we conflict with origin. Thomas Roessler: agree with Jeff. We need to nail down current practice, and then make it better. ???: should split permitted URI schemes and URIs. I think it's hard to be sure. Tobias: Peter, what do you think about x-frame-options?? Peter: it exists --> document it. Can't go back in time. Will take to the list whether this should be a WG draft - seems we have consensus on documenting X-frame-options (with the X-) 7. Admin / open mike - 14:15 [Open Mike] Larry Masinter: still waiting for response on his comments on MIME sniffing. Alexey: others as well. Thomas: when are you going to address MIME sniffing issues. When is it going to LC? Alexey: no idea at the moment. Masinter: my doc was an informational list of issues. Maybe this group can take them one-by-one. Pete Resnick: (not as AD) mime-sniff is problematic. Why should any perform this algorithm. It should be re-written. It's a horrible document to publish as protocol. Will submit his comments to the list this week. Tobias: any more? Tobias: to Thomas: looking at from-origin bits: should it be IETF work? Thomas: a bunch of people have thrown ideas around. Need to connect about this Yngve: just sent a link to a draft to the list. public suffix (PS) domain. How should I proceed with this. DNS people don't want to touch it. Thomas (as individual): interesting pickle. The existing hard-coded lists are important. Carrying meta-data about DNS in hard-coded lists is bad. Need to think about scalability and talk to Thomas Narten. In the future carrying a hard-coded list is not going to work as well as today. Jabber: Olafur says the DNS WG told him it was a bad idea. JeffH: at least one of the DNS Ext folks has an idea about handling the DNS suffix thing. Thomas: perhaps the right thing to do is to write a PS drafts Yngve: I think we need a central repository. My proposal is the best I can come up with. JeffH: +1 for the PS. Masinter: Worry about stuffing irrelevant data into DNS. Stuffing information about DNS is better. Tobias: who would write this PS draft? Peter: as an FYI this is interesting. If folks want to write a draft, they don't need to talk to me. Tobias: any more? We're adjourned. Finished in 14:32