Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 23 July 2011 16:18 UTC

Return-Path: <tobias.gondrom@gondrom.org>
X-Original-To: websec@ietfa.amsl.com
Delivered-To: websec@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6ABB921F8987 for <websec@ietfa.amsl.com>; Sat, 23 Jul 2011 09:18:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.362
X-Spam-Level:
X-Spam-Status: No, score=-95.362 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id H-Zf9+R+7IF2 for <websec@ietfa.amsl.com>; Sat, 23 Jul 2011 09:18:12 -0700 (PDT)
Received: from lvps83-169-7-107.dedicated.hosteurope.de (lvps83-169-7-107.dedicated.hosteurope.de [83.169.7.107]) by ietfa.amsl.com (Postfix) with ESMTP id 869E821F896E for <websec@ietf.org>; Sat, 23 Jul 2011 09:18:11 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=A1M4xpXfDd0J9BJdcOycRCIleAQ/1udk8K5xGuMU268jhz7vS1AWXTP85RghWkZkIO+ve0aENJgv6ejD9x+cWVmMUS0klDBWnCwtWbx+ag6Vr7jz2a8jRivwj4CMQ4Bk; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:References:In-Reply-To:Content-Type:Content-Transfer-Encoding;
Received: (qmail 7957 invoked from network); 23 Jul 2011 18:17:56 +0200
Received: from unknown (HELO ?172.17.9.73?) (207.134.107.2) by lvps83-169-7-107.dedicated.hosteurope.de with (DHE-RSA-AES256-SHA encrypted) SMTP; 23 Jul 2011 18:17:56 +0200
Message-ID: <4E2AF436.5070400@gondrom.org>
Date: Sat, 23 Jul 2011 17:17:58 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:5.0) Gecko/20110627 Thunderbird/5.0
MIME-Version: 1.0
To: websec@ietf.org
References: <4E177986.2030902@KingsMountain.com> <4E177D28.3070709@stpeter.im>
In-Reply-To: <4E177D28.3070709@stpeter.im>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
Subject: Re: [websec] specify existing X-Frame-Options ? (was: Re: FYI: New draft draft-gondrom-frame-options-01)
X-BeenThere: websec@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Web Application Security Minus Authentication and Transport <websec.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/websec>, <mailto:websec-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/websec>
List-Post: <mailto:websec@ietf.org>
List-Help: <mailto:websec-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/websec>, <mailto:websec-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 23 Jul 2011 16:18:12 -0000

Jeff,

actually part of doing frame-option was also inspired by Peter's "X-"draft.

You may be right and we could do a two-step approach and first document 
existing "X-Frame-Options" and then move forward. But actually I do not 
see much benefit of writing two drafts, the first describing existing 
X-Frame-Options further as there already is some sufficient documentation.
So I hoped to get both steps in one go by getting rid of the "X-" and 
making this an IETF standard "Frame-Options".

Kind regards, Tobias



On 08/07/11 22:56, Peter Saint-Andre wrote:
> On 7/8/11 3:41 PM, =JeffH wrote:
>>>> seems to me, this confusion&  potential issues are reasons to /not/
>>>> specify the header name as "Frame-Options" (for now), given
>>>> "X-FRAME-OPTIONS" apparent wide use.
>>> Sounds OK to me though I'd just want to be careful to do whatever the
>>> standards process dictates here.  I have to imagine there's a
>> precedent we'd
>>> want to follow.
>> there isn't much "process" wrt which we choose.
>>
>> In terms of precedent, AFAIK there's examples of both (a)
>> documenting/specifying current practice, and (b) documenting/specifying
>> how proponents would like various practices to evolve.
>>
>> Given that there's a fair number of web apps (aka websites) emitting
>> "X-FRAME-OPTIONS" (see below), and given its wide support in web
>> browsers, I think its justifiable to do (a), then see about (b).
>>
>> There's a recent I-D,
>> <http://tools.ietf.org/html/draft-saintandre-xdash>  'Use of the "X-"
>> Prefix in Application Protocols' (being discussed on
>> <apps-discuss@ietf.org>), which argues against its use. But in this case
>> current practice long predates said "X-" deprecation effort.
> Correct. This is a perfect example of how parameters leak out from the
> non-standard space into the standard space. Thus "X-" is unnecessary:
> someone could've just called it "Frame-Options" to start with. But as
> you say, that train has left the station...
>
> Peter
>