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

"Thomas Hardjono" <ietf@hardjono.net> Wed, 09 June 2010 01:09 UTC

Return-Path: <ietf@hardjono.net>
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 A2D0D3A6817 for <hasmat@core3.amsl.com>; Tue, 8 Jun 2010 18:09:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 h6h9E7acORIF for <hasmat@core3.amsl.com>; Tue, 8 Jun 2010 18:09:04 -0700 (PDT)
Received: from cpoproxy3-pub.bluehost.com (cpoproxy3-pub.bluehost.com [67.222.54.6]) by core3.amsl.com (Postfix) with SMTP id 301343A67A4 for <hasmat@ietf.org>; Tue, 8 Jun 2010 18:09:04 -0700 (PDT)
Received: (qmail 11254 invoked by uid 0); 9 Jun 2010 01:09:05 -0000
Received: from unknown (HELO box251.bluehost.com) (69.89.31.51) by cpoproxy3.bluehost.com with SMTP; 9 Jun 2010 01:09:05 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=hardjono.net; h=Received:From:To:References:In-Reply-To:Subject:Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding:X-Mailer:Thread-Index:Content-Language:X-Identified-User; b=SW9Tvz7dGLEjjW/OJcbBQWmur0hBFXoe0MiEpxCv0BmotibzY0Z6SHdLN3ilZxNvtrvVj0LVCUqbSKs/Ix8wjihOQZWarOa6KvMqor3kuHp8sTjm9smcd2dJMOi79Bj9;
Received: from ip-66-80-249-66.nyc.megapath.net ([66.80.249.66] helo=WINCE7P9IL9EJ0) by box251.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <ietf@hardjono.net>) id 1OM9my-0002EN-1x; Tue, 08 Jun 2010 19:09:05 -0600
From: Thomas Hardjono <ietf@hardjono.net>
To: '=JeffH' <Jeff.Hodges@KingsMountain.com>, 'IETF HASMAT list' <hasmat@ietf.org>
References: <4C0ED45D.9090006@KingsMountain.com>
In-Reply-To: <4C0ED45D.9090006@KingsMountain.com>
Date: Tue, 08 Jun 2010 21:08:58 -0400
Message-ID: <008b01cb0770$5a645ed0$0f2d1c70$@net>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AcsHY6pF9oDPV6DwSMGSBLC8vkH64QAC/tPw
Content-Language: en-us
X-Identified-User: {727:box251.bluehost.com:hardjono:hardjono.net} {sentby:smtp auth 66.80.249.66 authed with ietf@hardjono.net}
Subject: Re: [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: Wed, 09 Jun 2010 01:09:05 -0000

I'm just starting to read the drafts.

Quick nit/suggestion: Jeff, is there any chance of renaming STS to something
else?  Reason is (as you know) STS is used in WSS literature as Security
Token Service. This term has also made it into the OAuth drafts.

Perhaps something like: Transport Strict Security (TSS) might be better.
/thomas/



> -----Original Message-----
> From: hasmat-bounces@ietf.org [mailto:hasmat-bounces@ietf.org] On Behalf
Of
> =JeffH
> Sent: Tuesday, June 08, 2010 7:38 PM
> To: IETF HASMAT list
> Subject: [HASMAT] IETF BoF @IETF-78 Maastricht: HASMAT - HTTP Application
> Security Minus Authentication and Transport
> 
> [ 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
> 
> 
> 
> ###
> _______________________________________________
> HASMAT mailing list
> HASMAT@ietf.org
> https://www.ietf.org/mailman/listinfo/hasmat