[HASMAT] HASMAT/Websec Charter Proposal - last call - comments until Sep-8
Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 04 September 2010 16:15 UTC
Return-Path: <tobias.gondrom@gondrom.org>
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 D784F3A685E for <hasmat@core3.amsl.com>; Sat, 4 Sep 2010 09:15:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -93.945
X-Spam-Level:
X-Spam-Status: No, score=-93.945 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_20=-0.74, FH_HELO_EQ_D_D_D_D=1.597, FH_HOST_EQ_D_D_D_D=0.765, FM_DDDD_TIMES_2=1.999, HELO_DYNAMIC_IPADDR=2.426, HELO_EQ_DE=0.35, RDNS_DYNAMIC=0.1, USER_IN_WHITELIST=-100]
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 flKeHueEMA-v for <hasmat@core3.amsl.com>; Sat, 4 Sep 2010 09:15:35 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by core3.amsl.com (Postfix) with ESMTP id 33B713A686A for <hasmat@ietf.org>; Sat, 4 Sep 2010 09:15:34 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=EozdkChb14HUwi2Ngsa1ybfPOondIBdn8FfUe5K3D0h635FYxIUl2bnfA4/oVXkkcCBm12JnMBq0GBJ24dCKiOWoXN6CdT4F04kQwIvRSMQNklAW7Z31dPsVkNv2INo3; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:X-Priority:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 21930 invoked from network); 4 Sep 2010 18:15:55 +0200
Received: from 94-194-102-93.zone8.bethere.co.uk (HELO seraphim.heaven) (94.194.102.93) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 4 Sep 2010 18:15:55 +0200
Message-ID: <4C8270C8.3010605@gondrom.org>
Date: Sat, 04 Sep 2010 17:16:08 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.8) Gecko/20100802 SUSE/3.1.2 Lightning/1.0b2 Thunderbird/3.1.2
MIME-Version: 1.0
To: IETF HASMAT list <hasmat@ietf.org>
X-Priority: 2 (High)
References: <4C817C9A.1060105@KingsMountain.com>
In-Reply-To: <4C817C9A.1060105@KingsMountain.com>
X-Enigmail-Version: 1.1.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Subject: [HASMAT] HASMAT/Websec Charter Proposal - last call - comments until Sep-8
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: Sat, 04 Sep 2010 16:15:37 -0000
Dear all, as I haven't seen too much controversy on the charter, to get the work going I like to close final comments on the initial charter and the name of the new WG until Sep-8. After that we should submit the final proposal to the AD and get to the more important work on the drafts. Best regards, Tobias Ps.: We need to finish the formal stuff (name, charter) for the WG until Sep-12 so that we are in time before the cut-off date to book the meeting slot for Beijing and so we can focus on the real stuff: the drafts. ====================================================== Charter for WebSec -- Web Security 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 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. HTML5, 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 Appendix A. Relationship of Origin work in IETF WebSec and in W3C HTML5 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. 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). --- end
- Re: [HASMAT] HASMAT Charter Proposal (revised-01) =JeffH
- [HASMAT] HASMAT/Websec Charter Proposal - last ca… Tobias Gondrom
- Re: [HASMAT] HASMAT Charter Proposal (revised-01) Tobias Gondrom
- Re: [HASMAT] HASMAT/Websec Charter Proposal - las… Julian Reschke
- Re: [HASMAT] HASMAT/Websec Charter Proposal - las… Tobias Gondrom