* WGs marked with an * asterisk has had at least one new draft made available during the last 5 days

Websec Status Pages

Web Security (Active WG)
App Area: Pete Resnick, Barry Leiba | 2010-Oct-12 —  
Chairs
 
 


2014-04-29 charter

Web Security (websec)
---------------------

 Charter

 Current Status: Active

 Chairs:
     Tobias Gondrom <tobias.gondrom@gondrom.org>
     Yoav Nir <ynir.ietf@gmail.com>

 Applications Area Directors:
     Barry Leiba <barryleiba@computer.org>
     Pete Resnick <presnick@qti.qualcomm.com>

 Applications Area Advisor:
     Barry Leiba <barryleiba@computer.org>

 Tech Advisor:
     Sean Turner <turners@ieca.com>

 Mailing Lists:
     General Discussion: websec@ietf.org
     To Subscribe:       https://www.ietf.org/mailman/listinfo/websec
     Archive:            http://www.ietf.org/mail-archive/web/websec/

Description of Working Group:


    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.

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




Goals and Milestones:
  Done     - Submit 'HTTP Application Security Problem Statement and Requirements' as initial WG item.
  Done     - Submit 'Media Type Sniffing' as initial WG item.
  Done     - Submit 'Web Origin Concept' as initial WG item.
  Done     - Submit 'Strict Transport Security' as initial WG item.
  Done     - Submit 'Web Origin Concept' to the IESG for consideration as a Standards Track RFC.
  Done     - Submit 'Strict Transport Security' to the IESG for consideration as a Standards Track RFC.
  Done     - Adopt 'Frame-Options' as initial WG item.
  Done     - Adopt 'X-Frame-Options' as initial WG item.
  Done     - Submit 'X-Frame-Options' to the IESG for consideration as a Informational Track RFC.
  Done     - Adopt 'HTTP Application Security Problem Statement and Requirements' as initial WG item.
  May 2013 - Submit 'Public Key Pinning Extension for HTTP' to the IESG for consideration as a Standards Track RFC.
  Jul 2013 - Submit 'HTTP Application Security Problem Statement and Requirements' to the IESG for consideration as an Informational RFC.


All charter page changes, including changes to draft-list, rfc-list and milestones:



Generated from PyHt script /wg/websec/charters.pyht Latest update: 24 Oct 2012 16:51 GMT -