MINUTES: HTTP Application Security Minus Authentication and Transport BOF ========================================================================= [ IETF Applications Area ] IETF-78 Maastricht TUESDAY, July 27, 2010 1300-1500 Afternoon Session I Room: 0.1 London Chairs: Jeff Hodges Hannes Tschofenig Sponsoring AD: Peter Saint-Andre Minute taker: Spencer Dawkins Agenda: http://www.ietf.org/proceedings/78/agenda/hasmat.txt 1.1 HASMAT 1.1.1 Agenda bashing (Chairs) No bashing. 1.1.2 Problem space description (Jeff) slides: http://www.ietf.org/proceedings/78/slides/hasmat-0.pdf "The need for a coherent web security policy framework, or why Frankenstein's monster can't rule the world." Compact survey paper, referencing other papers. Web evolved organically, wasn't actually designed, so security is not part of the design (or lack thereof). When you put commerce on top of that, you have problems. Six attacks listed on the slides are the tip of the iceberg. Current security policies are sprinkled all over the web (HTTP headers, cookies, Meta tags, .) Result is a mess. What we want is something that's actually designed. The right way to set policy is via configurable declaration, not (hard) code. Current mechanisms require every developer to do the right thing, every time. We have individual drafts in Web Security - put this in a working group? There's also W3C work we'd need to coordinate with. Hannes - as IAB member, looking at architectural impacts, and what the near term/long term situation looks like, and what a reasonable split between W3C and IETF might look like. Sam Weiler - TLS@DNSSEC Bar BOF on what happens when the name in DNS doesn't match the name you're validating - but they were going to start with TLS. 1.1.3 Related Work (Adam) slides: http://www.ietf.org/proceedings/78/slides/hasmat-2.ppt What web security is like, and how the pieces fit together. Standard web security assumptions- Assume an honest browser ("client is trusted"), that isolates different sites. The user visits malicious websites (and/or there's a network attacker), and the user's computer doesn't have malware. Lots of isolation policies, so lots of mechanisms that don't match all the isolation policies. Cookies are per-domain, but tags can read from/send to anywhere. More modern APIs use a same-origin policy. is subtle - lets you draw an image from anywhere, but you can't read an image you've drawn. Lots of challenge problems (client-side and server-side problems). 1.1.4 Proposed Documents Short summaries of the proposed docs by the authors... http://tools.ietf.org/html/draft-abarth-origin-07 slides: http://www.ietf.org/proceedings/78/slides/hasmat-3.ppt Nobody's actually written down what the "same-origin policy" might be. Need to describe how to compare two origins, and to serialize to ASCII and to Unicode - this draft provides these descriptions. Can you allow a "man in the middle" that you trust? In many models, the proxy is part of your trusted domain. Are multiple languages lumped into a single origin? This stuff is nothing new - but it's never been written down. http://tools.ietf.org/html/draft-abarth-mime-sniff-05 Slides: slides: http://www.ietf.org/proceedings/78/slides/hasmat-4.ppt Browsers sometimes ignore Content-Type (about one percent of HTTP responses). Leads to tricky attacks - every browser is different. This draft defines a standard "sniffing" algorithm. It's already been deployed in some browsers. Spec explicitly allows a client to not sniff - it's optional. http://tools.ietf.org/html/draft-hodges-strict-transport-sec-02 slides: http://www.ietf.org/proceedings/78/slides/hasmat-1.pdf Various vulnerabilities with HTTP over TLS/SSL today - passive attackers with incorrectly-deployed "secure" sites can leak "non-Secure" session cookies, active attackers can spoof DNS servers, "click-through insecurity", and web site bugs (single unsecured load of CSS or SWF on otherwise-secure SSL/TLS site can compromise entire site). Sites need to be able to declare "interact with me only in secure fashion!" to browsers. Browsers need to terminate secure connection without giving user possible recourse. HSTS Policy Advertisement via "Strict-Transport-Security" HTTP response header. Implemented in Chrome, Firefox and NoScript. www.paypal.com uses HSTS policy mechanism. Sam Weiler - has this been used for a DOS? Haven't seen it. Wes Hardaker - you're still doing a one-time leap of faith, right? Successful operation tells client "never go back to HTTP again". Chrome has a preloaded list of sites; you can get on that list. DNSSEC could be used, further down the road. EKR - these are point solutions, which are great, but how does that fit with your overall solution story? Would like to figure out more generic policy framework. 1.1.5 Presentation of charter text (Chairs) Longer-term vision hasn't been worked out, difficult to say how we get there. EKR would endorse this language and negative-endorse the policy language for now - this community needs to understand policy better before we charter that work. Proposing to finish up initial three documents, and do research (and write it down), and think about rechartering then. EKR - would nitpick the introduction, but don't have any problem with this. Thomas Roessler-W3C - W3C work describes the space a policy framework would work on, how you communicate. Need a good understanding of the problem statement as Adam describes - should have that in Web Applications Security group we're spinning up in W3C. Neither side should attempt this one their own. Who gets to call their work WEBSEC? Mark Nottingham - agree that web policy is huge rathole, Paul Hoffman - what's going to be coordinated, and what's going to be primarily done in each SDO. HTTP work a decade ago showed this was critical. We don't need to know at every moment, but we have layer 9 problems on both sides, all the time. If we think something is important but W3C people are working on it, we can lose a major part. We don't even know if we can work in those working groups. Mark, as IETF liaison to W3C - we have a very active liaison with W3C, these topics have been on every coordination call for the past year. If people see work diverging, come to the liaisons, we'll need to crack heads. (JeffH is PayPal's AC representative to W3C) Lots of items in isolation, not sure how much this will help. Why not let W3C do this without us? Do they need our help? JeffH - the closer the work gets to protocol work, the more it belongs here. St. Peter - lots of productive discussions. Don't have answers yet, but we're coming to conclusions - that's why we wanted to have this BOF. Need to come to conclusions and write conclusions down, of course (APPS ADs come and go). Origin policies aren't HTTP-specific - if they apply to SIP or to IMAP, they need to happen in the IETF. Thomas - agreed. How can we cultivate a community where we communicate across the aisle, review each other's work, etc. Want to work this on the IETF side, think that's a positive outcome we could get from a working group. 1.1.6 Discussion of charter text and choice of the initial specifications (All) 1.1.7 Conclusion (Chairs/ADs) Hum - Is it useful to work on this, in the IETF? St. Peter - what is "this"? Text on the screen, right? Right. Uniform agreement that we should do this work. Hannes summarized the charter text for a couple of people in the room who hadn't grokked the text on the screen. Hum - are you OK with charter text modulo discussion we've just had? Again, uniform agreement for the charter text. EKR - whining about motivational text, but take that as read, and I can hum for itJ. Reviewers? 20 in the room. Contributors? 5 in the room. Chairs discussion will happen offline.