- From: Mark Nottingham <mnot@mnot.net>
- Date: Sat, 2 Oct 2010 11:37:45 +1000
- To: HTTP Working Group <ietf-http-wg@w3.org>
In case you haven't seen it... Begin forwarded message: > From: Peter Saint-Andre <stpeter@stpeter.im> > Date: 29 September 2010 3:47:59 AM AEST > To: "apps-discuss@ietf.org" <apps-discuss@ietf.org> > Subject: [apps-discuss] Fwd: WG Review: Web Security (websec) > > FYI. > > -------- Original Message -------- > Subject: WG Review: Web Security (websec) > Date: Tue, 28 Sep 2010 10:15:06 -0700 (PDT) > From: IESG Secretary <iesg-secretary@ietf.org> > Reply-To: iesg@ietf.org > To: ietf-announce@ietf.org > CC: hasmat@ietf.org > > A new IETF working group has been proposed in the Applications Area. The > IESG has not made any determination as yet. The following draft charter > was submitted, and is provided for informational purposes only. Please > send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, > October 5, 2010. > > Web Security (websec) > --------------------------------------------- > Status: Proposed Working Group > Last updated: 2010-09-23 > > Chairs(s) > Tobias Gondrom <tobias.gondrom@gondrom.org> > > Applications Area Directors: > Alexey Melnikov <alexey.melnikov@isode.com> > Peter Saint-Andre <stpeter@stpeter.im> > > Applications Area Advisor: > Peter Saint-Andre <stpeter@stpeter.im> > > Security Area Advisor: > Sean Turner <turners@ieca.com> > > Mailing Lists: > General Discussion: hasmat@ietf.org > To Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat> > Archive: <http://www.ietf.org/mail-archive/web/hasmat/> > [to be changed to websec@ietf.org if approved] > > Problem Statement > > Although modern Web applications are built on top of HTTP, they provide > rich functionality and have requirements beyond the original vision of > static web pages. HTTP, and the applications built on it, have evolved > organically. Over the past few years, we have seen a proliferation of > AJAX-based web applications (AJAX being shorthand for asynchronous > JavaScript and XML), as well as Rich Internet Applications (RIAs), based > on so-called Web 2.0 technologies. These applications bring both > luscious eye-candy and convenient functionality, e.g. social networking, > to their users, making them quite compelling. At the same time, we are > seeing an increase in attacks against these applications and their > underlying technologies. > > The list of attacks is long and includes Cross-Site-Request Forgery > (CSRF)-based attacks, content-sniffing, cross-site-scripting (XSS) > attacks, attacks against browsers supporting anti-XSS policies, > clickjacking attacks, malvertising attacks, as well as man-in-the-middle > (MITM) attacks against "secure" (e.g. Transport Layer Security > (TLS/SSL)-based) web sites along with distribution of the tools to carry > out such attacks (e.g. sslstrip). > > Objectives and Scope > > With the arrival of new attacks the introduction of new web security > indicators, security techniques, and policy communication mechanisms > have sprinkled throughout the various layers of the Web and HTTP. > > The goal of this working group is to compose an overall "problem > statement and requirements" document derived from surveying the > issues outlined in the above section ([1] provides a starting point). > The requirements guiding the work will be taken from the Web > application and Web security communities. The scope of this document > is HTTP applications security, but does not include HTTP authentication, > nor internals of transport security which are addressed by other working > groups (although it may make reference to transport security as an > available security "primitive"). See the "Out of Scope" section, below. > > Additionally, the WG will standardize a small number of selected > specifications that have proven to improve security of Internet > Web applications. Initial work will be the following topics: > > - Same origin policy, as discussed in draft-abarth-origin > (see also Appendices A and B, below) > > - HTTP Strict transport security, as discussed in > draft-hodges-strict-transport-sec > > - Media type sniffing, as discussed in draft-abarth-mime-sniff > > This working group will work closely with IETF Apps Area WGs (such as > HYBI, HTTPstate, and HTTPbis), as well as appropriate W3C working > group(s) (e.g. HTML, WebApps). > > Out of Scope > > As noted in the objectives and scope (above), this working group's > scope does not include working on HTTP Authentication nor underlying > transport (secure or not) topics. So, for example, these items are > out-of-scope for this WG: > > - Replacements for BASIC and DIGEST authentication > > - New transports (e.g. SCTP and the like) > > Deliverables > > 1. A document illustrating the security problems Web applications are > facing and listing design requirements. This document shall be > Informational. > > 2. A selected set of technical specifications documenting deployed > HTTP-based Web security solutions. These documents shall be Standards > Track. > > Goals and Milestones > > Oct 2010 Submit "HTTP Application Security Problem Statement and > Requirements" as initial WG item. > > Oct 2010 Submit "Media Type Sniffing" as initial WG item. > > Oct 2010 Submit "Web Origin Concept" as initial WG item. > > Oct 2010 Submit "Strict Transport Security" as initial WG item. > > Feb 2011 Submit "HTTP Application Security Problem Statement and > Requirements" to the IESG for consideration as an > Informational RFC. > > Mar 2011 Submit "Media Type Sniffing" to the IESG for consideration > as a Standards Track RFC. > > Mar 2011 Submit "Web Origin Concept" to the IESG for consideration as > a Standards Track RFC. > > Mar 2011 Submit "Strict Transport Security" to the IESG for > consideration as a Standards Track RFC. > > Apr 2011 Possible re-chartering > > References > > [1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy > Framework", W2SP position paper, 2010. > http://w2spconf.com/2010/papers/p11.pdf > > Appendices > > A. Relationship between origin work in IETF WebSec and W3C HTML WG > > draft-abarth-origin defines the nuts-and-bolts of working with > origins (computing them from URIs, comparing them to each other, etc). > HTML5 defines HTML-specific usage of origins. For example, when > making an HTTP request, HTML5 defines how to compute which origin > among all the origins rendering HTML is the one responsible for making > the request. draft-abarth-origin then takes that origin, serializes > it to a string, and shoves it in a header. > > B. Origin work may yield two specifications > > There also seems to be demand for a document that describes the > same-origin security model overall. However, it seems like that > document ought to be more informative rather than normative. The > working group may split draft-abarth-origin into separate informative > and standards track specifications, the former describing same-origin > security model, and the latter specifying the nuts-and-bolts of working > with origins (computing them from URLs, comparing them to each other, > etc). > _______________________________________________ > apps-discuss mailing list > apps-discuss@ietf.org > https://www.ietf.org/mailman/listinfo/apps-discuss -- Mark Nottingham http://www.mnot.net/
Received on Saturday, 2 October 2010 01:38:18 UTC