IETF-88 Proceedings

Introduction  |  Area, Working Goup & BoF Reports  |  Plenaries  |  Training  |  Internet Research Task Force

Web Security (websec) (WG)

Minutes   |   Audio Archives  |   Jabber Logs  |   Mailing List Archives

Additional information is available at


Applications Area Area Director(s):

Applications Area Advisor

Technical Advisor(s)

Meeting Slides:

No Slides Present


Request for Comments:

Charter (as of 2010-10-12):

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

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


1. A document illustrating the security problems Web applications are
facing and listing design requirements. This document shall be

2. A selected set of technical specifications documenting deployed
HTTP-based Web security solutions. These documents shall be Standards


[1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy
Framework", W2SP position paper, 2010.


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,

Internet SocietyAMSHome - Tools Team - Datatracker - Web Site Usage Statistics - IASA - IAB - RFC Editor - IANA - IRTF - IETF Trust - ISOC - Store - Contact Us
Secretariat services provided by Association Management Solutions, LLC (AMS).
Please send problem reports to: