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

["Jeffrey A. Williams" <[e-mail]>]

Paul and all,

  This is good stuff and a necesarry WG IMPO.  BTW,
whomever wrote this up did a bang up job!  >:)


-----Original Message-----
>From: Paul Hoffman <[e-mail]>
>Sent: Sep 28, 2010 12:28 PM
>To: [e-mail]
>Subject: [keyassure] Fwd: WG Review: Web Security (websec)
>
>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).
>
>_______________________________________________
>keyassure mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/keyassure

Regards,
Jeffrey A. Williams
"Obedience of the law is the greatest freedom" -
   Abraham Lincoln

"Credit should go with the performance of duty and not with what is very
often the accident of glory" - Theodore Roosevelt

"If the probability be called P; the injury, L; and the burden, B; liability
depends upon whether B is less than L multiplied by
P: i.e., whether B is less than PL."
United States v. Carroll Towing  (159 F.2d 169 [2d Cir. 1947]
===============================================================
ABA member in good standing member ID 01257402 E-Mail [e-mail]
Phone: [phone]