Fwd: [apps-discuss] Fwd: WG Review: Web Security (websec)

[Mark Nottingham <[e-mail]>]

In case you haven't seen it...


Begin forwarded message:

> From: Peter Saint-Andre <[e-mail]>
> Date: 29 September 2010 3:47:59 AM AEST
> To: "[e-mail]" <[e-mail]>
> 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 <[e-mail]>
> Reply-To: [e-mail]
> To: [e-mail]
> CC: [e-mail]
> 
> 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 ([e-mail]) by Tuesday,
> October 5, 2010.
> 
> Web Security (websec)
> ---------------------------------------------
> Status: Proposed Working Group
> Last updated: 2010-09-23
> 
> Chairs(s)
>   Tobias Gondrom <[e-mail]>
> 
> Applications Area Directors:
>   Alexey Melnikov <[e-mail]>
>   Peter Saint-Andre <[e-mail]>
> 
> Applications Area Advisor:
>   Peter Saint-Andre <[e-mail]>
> 
> Security Area Advisor:
>   Sean Turner <[e-mail]>
> 
> Mailing Lists:
>  General Discussion: [e-mail]
>  To Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>
>  Archive: <http://www.ietf.org/mail-archive/web/hasmat/>
>  [to be changed to [e-mail] 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/apps-discuss

--
Mark Nottingham   http://www.mnot.net/