[keyassure] Fwd: WG Review: Web Security (websec)

[Paul Hoffman <[e-mail]>]

This is of interest to this still-not-yet-a-Working-Group, including at least one of the three documents listed in the middle of the proposed charter.

>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).