[HASMAT] IETF BoF @IETF-78 Maastricht: HASMAT - HTTP Application Security Minus Authentication and Transport

=JeffH <Jeff.Hodges@KingsMountain.com> Tue, 08 June 2010 23:38 UTC

Return-Path: <Jeff.Hodges@KingsMountain.com>
X-Original-To: hasmat@core3.amsl.com
Delivered-To: hasmat@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A46DE3A6833 for <hasmat@core3.amsl.com>; Tue, 8 Jun 2010 16:38:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.335
X-Spam-Level:
X-Spam-Status: No, score=0.335 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_50=0.001, IP_NOT_FRIENDLY=0.334]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V3sCXxCGjjVU for <hasmat@core3.amsl.com>; Tue, 8 Jun 2010 16:38:07 -0700 (PDT)
Received: from cpoproxy1-pub.bluehost.com (cpoproxy1-pub.bluehost.com [69.89.21.11]) by core3.amsl.com (Postfix) with SMTP id 5BF4B3A6886 for <hasmat@ietf.org>; Tue, 8 Jun 2010 16:38:07 -0700 (PDT)
Received: (qmail 19776 invoked by uid 0); 8 Jun 2010 23:38:08 -0000
Received: from unknown (HELO box514.bluehost.com) (74.220.219.114) by cpoproxy1.bluehost.com with SMTP; 8 Jun 2010 23:38:08 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=kingsmountain.com; h=Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Content-Transfer-Encoding:X-Identified-User; b=1h02pkXoa2jI45XqJ7TWFZn9H1LrYCDG9WAC2uACn2Fg0JJVcCPM6+19DZPbeKfC6gUd75ou/OYWQPmG/wu0KI3xOqA1I5FQOZHi3BvoEzDxwuHKIZ3p8rc2Tgv1iOEO;
Received: from c-24-4-121-38.hsd1.ca.comcast.net ([24.4.121.38] helo=[192.168.11.10]) by box514.bluehost.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.69) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1OM8My-0004xg-Du for hasmat@ietf.org; Tue, 08 Jun 2010 17:38:08 -0600
Message-ID: <4C0ED45D.9090006@KingsMountain.com>
Date: Tue, 08 Jun 2010 16:38:05 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
User-Agent: Thunderbird 2.0.0.24 (X11/20100411)
MIME-Version: 1.0
To: IETF HASMAT list <hasmat@ietf.org>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth 24.4.121.38 authed with jeff.hodges+kingsmountain.com}
Subject: [HASMAT] IETF BoF @IETF-78 Maastricht: HASMAT - HTTP Application Security Minus Authentication and Transport
X-BeenThere: hasmat@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: HTTP Application Security Minus Authentication and Transport <hasmat.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/hasmat>
List-Post: <mailto:hasmat@ietf.org>
List-Help: <mailto:hasmat-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/hasmat>, <mailto:hasmat-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 08 Jun 2010 23:38:10 -0000

[ this is a more full-featured HASMAT BoF announcement that we'll be sending 
out to various other lists, both IETF and non-IETF, later today and tomorrow, 
feedback welcome (send it soon if you can ;)   I incorp'd the lastest charter 
draft ]


We will be hosting the "HTTP Application Security Minus Authentication and 
Transport (HASMAT)" Birds-of-a-Feather (BoF) session at IETF-78 in Maastricht 
NL during the week of July 25-30, 2010.

The purpose of IETF BoFs is to determine whether there is a problem worth 
solving, and whether the IETF is the right group to solve it. To that end, the 
problem statement is summarized below in the Draft HASMAT Working Group 
Charter, and is drawn from [1].

Various facets of this work are already underway, as outlined below in the 
draft WG charter, e.g. Strict Transport Security (STS) [2].

Of course the scope of "HTTP application security" is quite broad (as outlined 
in [1]), thus the intent is to coordinate this work closely with related work 
likely to land in the W3C (and possibly other orgs), e.g. Content Security 
Policy (CSP) [3].

We have created a public mailing list for pre-BoF discussion -- hasmat@ietf.org 
-- to which you can freely subscribe here: 
<https://www.ietf.org/mailman/listinfo/hasmat>

We encourage all interested parties to join the mailing list and engage in the 
on-going discussion there.

thanks,

=JeffH             (current HTTPstate WG chair)
Peter Saint-Andre  (IETF Applications Area Director)
Hannes Tschofenig  (IAB, IETF WG chair)


[0] HASMAT mailing list.
https://www.ietf.org/mailman/listinfo/hasmat

[1] Hodges and Steingruebl, "The Need for a Coherent Web Security Policy 
Framework", W2SP position paper, 2010.
http://w2spconf.com/2010/papers/p11.pdf

[2] Hodges, Jackson, and Barth, "Strict Transport Security (STS)",
revision -06.
http://lists.w3.org/Archives/Public/www-archive/2009Dec/att-0048/draft-hodges-strict-transport-sec-06.plain.html 

see also: http://en.wikipedia.org/wiki/Strict_Transport_Security

[3] Sterne and Stamm, "Content Security Policy (CSP)".
https://wiki.mozilla.org/Security/CSP/Specification
see also: http://people.mozilla.org/~bsterne/content-security-policy/
           https://wiki.mozilla.org/Security/CSP/Design_Considerations


###

Proposed HASMAT BoF agenda
--------------------------

Chairs: Hannes Tschofenig and Jeff Hodges

5 min   Agenda bashing (Chairs)

10 min  Description of the problem space (TBD)

20 min  Motivation for standardizing (TBD)
         draft-abarth-mime-sniff
         draft-abarth-origin (expired)
         draft-hodges-stricttransportsec (to-be-submitted)

15 min  Presentation of charter text (TBD)

60 min  Discussion of charter text and choice of the initial
specifications (All)

10 min  Conclusion (Chairs/ADs)



###

Draft Charter for HASMAT:

    HTTP Application Security Minus Authentication and Transport WG


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 standardize a small number of
selected specifications that have proven to improve security of Internet
Web applications. The requirements guiding the work will be taken from
the Web application and Web security communities.  Initial work will be
limited to the following topics:

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

    - Strict transport security, as discussed in
      draft-hodges-stricttransportsec (to be submitted shortly)

    - Media type sniffing, as discussed in draft-abarth-mime-sniff

In addition, this working group will consider the overall topic of HTTP
application security and compose a "problem statement and requirements"
document that can be used to guide further work.

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 this working group's title, 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



###