Re: [HASMAT] HASMAT Charter Proposal (revised-01)

[Tobias Gondrom <[e-mail]>]

 Jeff,

excellent. Thank you. I like the charter and think it's good to go.

Maybe two  very minor personal editorial suggestions
1. in the section "Objectives and Scope" second paragraph.
current: "The scope of this document is HTTP applications security, but
does not include HTTP authentication, nor internals of transport
security (although it may make reference to transport security as an
available security "primitive")."
revised: "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")."

reason: This way unfamiliar readers will know the rationale why we
excluded this and can look elsewhere.

2. section "Objectives and Scope", third paragraph:
current: "Initial work will be limited to the following topics:"
new: "Initial work will be the following topics:"

reason: no need to limit this so formally, but rather state what we are
doing first, allows it open to add stuff which is in scope of the
charter later once the ball is rolling.

These are only my personal comments and from my perspective only very
minor and editorial.

Best regards, Tobias




On 09/03/2010 11:54 PM, =JeffH wrote:
> enhanced per Roessler's and ABarth's comments/discussion.
>
> Further comments?
>
> thanks,
>
> =JeffH
> ------
>
> Charter for WebSec -- Web Security WG
> [ formerly known as HASMAT - HTTP Application Security Minus
> Authentication and
> Transport ]
>
> 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 (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 limited to 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. HTML5, 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
>
> Appendix
>
> A. Relationship of Origin work in IETF WebSec and in W3C HTML5
>
> draft-abarth-origin defines the nuts-and-bolts of working with
> origins (computing them from URLs, 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).
>
>
> ---
> end
>
>
>
>
> _______________________________________________
> HASMAT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hasmat