Subject: Re: [HASMAT] HASMAT Charter Proposal (revised)

From: =JeffH <[email-masked]>
Date: Thu, 02 Sep 2010 16:44:04 -0700

I've revised the proposed charter per Barry's comment.

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

    - 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 W3C WebApps working group(s).

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

---
end

---

From: Thomas Roessler <[email-masked]>
Date: Fri, 3 Sep 2010 11:02:09 +0200

> I've revised the proposed charter per Barry's comment.

Thanks.

>   - Same origin policy, as discussed in draft-abarth-origin

draft-abarth-origin defines the origin concept and a corresponding HTTP header.

The same-origin policies typically involve a lengthy decision tree about where to take the origin from, e.g.:
	http://dev.w3.org/html5/spec/origin-0.html#relaxing-the-same-origin-restriction

Adam, can you elaborate a bit more how, in detail, you see the relationship between your draft and HTML5 play out?  And can we talk about that in the charter?

> Apr 2011    Possible re-chartering

I'm trying to think through the relationship between this time line and the Web Application Security WG idea at W3C:
	http://www.w3.org/2010/07/appsecwg-charter.html

In particular, to what extent do we expect the requirements document out of the IETF WG to directly influence whatever the W3C group does with CSP?

(Note that, on the IETF side of things, it's rational to recharter after the requirements document has been developed.  I'd prefer to avoid that on the W3C side if possible, since a rechartering is more costly -- though not impossible -- there.)

Thoughts?

---

From: Adam Barth <[email-masked]>
Date: Fri, 3 Sep 2010 10:04:34 -0700

On Fri, Sep 3, 2010 at 2:02 AM, Thomas Roessler <[email-masked]> wrote:
> Adam, can you elaborate a bit more how, in detail, you see the relationship between your draft and HTML5 play out?

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

Originally, draft-abarth-origin was part of HTML5, but there are a
number of other standards that wanted to interact with origins.  For
example, Hybi would like to serialize an origin and place the octets
somewhere on the wire.  Rather than have these folks refer "up the
stack" to the application layer (e.g., HTML5), it seems to make more
sense to move the non-application specific parts lower down in the
stack.  Of course, the application-specific parts (e.g., that the
toDataURL method on the <canvas> element behaves different depending
on the origins of things drawn on the canvas) will remain at the
application layer.

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.  I've
started sketching out something in that regard:

https://docs.google.com/document/pub?id=1p2t8ZOAcwduqrS-NPAlSMtBDaDBg3PDBED625rTvctw

That's a pretty rough draft, but it should give you an idea of the
direction for that document.  Once I get that finished up, I'd like to
publish it in some forum, but it's unclear to me at this point what
forum would be most appropriate.

> And can we talk about that in the charter?

I'll leave that up to the folks who've been working on the charter directly.

Adam