-------- Original Message --------
Subject: Fwd: [apps-discuss] Fwd: WG Review: Web Security (websec)
Resent-Date: Sat, 02 Oct 2010 01:38:30 +0000
Date: Sat, 2 Oct 2010 11:37:45 +1000
From: Mark Nottingham <mnot@...
To: HTTP Working Group <ietf-http-wg@...
In case you haven't seen it...
Begin forwarded message:
> From: Peter Saint-Andre <stpeter@...>
> Date: 29 September 2010 3:47:59 AM AEST
> To: "apps-discuss@..." <apps-discuss@...>
> Subject: [apps-discuss] Fwd: WG Review: Web Security (websec)
> -------- Original Message --------
> Subject: WG Review: Web Security (websec)
> Date: Tue, 28 Sep 2010 10:15:06 -0700 (PDT)
> From: IESG Secretary <iesg-secretary@...>
> Reply-To: iesg@...
> To: ietf-announce@...
> CC: hasmat@...
> 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@...) by Tuesday,
> October 5, 2010.
> Web Security (websec)
> Status: Proposed Working Group
> Last updated: 2010-09-23
> Tobias Gondrom <tobias.gondrom@...>
> Applications Area Directors:
> Alexey Melnikov <alexey.melnikov@...>
> Peter Saint-Andre <stpeter@...>
> Applications Area Advisor:
> Peter Saint-Andre <stpeter@...>
> Security Area Advisor:
> Sean Turner <turners@...>
> Mailing Lists:
> General Discussion: hasmat@...
> To Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>
> Archive: <http://www.ietf.org/mail-archive/web/hasmat/>
> [to be changed to websec@... 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
> 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 ( 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
> - 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)
> 1. A document illustrating the security problems Web applications are
> facing and listing design requirements. This document shall be
> 2. A selected set of technical specifications documenting deployed
> HTTP-based Web security solutions. These documents shall be Standards
> 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
>  Hodges and Steingruebl, "The Need for a Coherent Web Security Policy
> Framework", W2SP position paper, 2010.
> 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,
> apps-discuss mailing list
Mark Nottingham http://www.mnot.net/