Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT)

Tobias Gondrom <tobias.gondrom@gondrom.org> Sat, 17 August 2013 22:46 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 7182411E81A3 for <websec@ietfa.amsl.com>; Sat, 17 Aug 2013 15:46: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=[AWL=0.000, 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 ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NrR8ud+sWlIp for <websec@ietfa.amsl.com>; Sat, 17 Aug 2013 15:46:07 -0700 (PDT)
Received: from lvps176-28-13-69.dedicated.hosteurope.de (lvps176-28-13-69.dedicated.hosteurope.de [176.28.13.69]) by ietfa.amsl.com (Postfix) with ESMTP id E485C21F9935 for <websec@ietf.org>; Sat, 17 Aug 2013 15:45:40 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gondrom.org; b=fOvp1GtYd7cmgm0NhABtxd1RXC+mZwW0ap0h97ZBoE0ZMBS9yxk248oxVz2se7ERedkT61WSTwCWAbhi9BZILVWDhnDpAalqUZy58zPH6QCyT5EIfassImbEF3Q1OFBU; h=Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:References:In-Reply-To:X-Enigmail-Version:Content-Type:Content-Transfer-Encoding;
Received: (qmail 24198 invoked from network); 18 Aug 2013 00:45:31 +0200
Received: from 188-222-103-191.zone13.bethere.co.uk (HELO ?192.168.1.64?) (188.222.103.191) by lvps176-28-13-69.dedicated.hosteurope.de with ESMTPSA (DHE-RSA-AES256-SHA encrypted, authenticated); 18 Aug 2013 00:45:31 +0200
Message-ID: <520FFD0B.5040504@gondrom.org>
Date: Sat, 17 Aug 2013 23:45:31 +0100
From: Tobias Gondrom <tobias.gondrom@gondrom.org>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130804 Thunderbird/17.0.8
MIME-Version: 1.0
To: ted.lemon@nominum.com
References: <20130814175121.16080.58938.idtracker@ietfa.amsl.com> <520BF1AB.5000103@gondrom.org> <0B70B4E8-0375-414F-B529-52D3EE0E275B@nominum.com>
In-Reply-To: <0B70B4E8-0375-414F-B529-52D3EE0E275B@nominum.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="windows-1252"
Content-Transfer-Encoding: 8bit
Cc: draft-ietf-websec-x-frame-options@tools.ietf.org, websec@ietf.org, iesg@ietf.org, websec-chairs@tools.ietf.org
Subject: Re: [websec] Ted Lemon's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT)
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, 17 Aug 2013 22:46:12 -0000

On 14/08/13 22:49, Ted Lemon wrote:
> On Aug 14, 2013, at 5:07 PM, Tobias Gondrom <tobias.gondrom@gondrom.org> wrote:
>> I had the hope with referring to RFC6454 this should be unambiguous and
>> clear enough. I had the hesitation to write redundant text, but maybe I
>> got too short. Do you think we need to spell it out more explicitly in
>> the draft so people understand?
> How about:
>
>   Existing implementations differ with [RFC6454] in that origins with
>   the same protocol but different port values are considered equivalent.
Ok. I added the sentence you suggested in version-10 as:
"I.e. existing implementations differ with [RFC6454] in that origins
with the same protocol but different port values are considered equivalent."

>
>>> What is the distinction between "top-level browsing context" and "origin
>>> of the framing page?"   A reference here would be helpful.
>> Apologies. In this case I have hesitations to add an explanation about
>> the nesting of frames in html. In general the concept of nested frames
>> (and top-level vs. framing page) is reasonably understood.
>> [will keep the text as is until I hear an argument that this really
>> needs an explanation in this draft.]
> The additional text that you added in your reply helps a little—it appears that "top-level browsing context" means "the HTML that is loaded first and that contains whatever nesting might occur" and perhaps that "origin of the framing page" refers somehow to the idea of nested frames.   But even with the help you've given me in your reply, I am not sure that I have this right, and indeed I am scratching my head trying to figure out what the difference is between these two contexts.
>
> As a person who writes HTML fairly regularly, I think I am your intended target audience.   If so, you really do need to explain what these terms mean, or provide a reference to a document that explains them.
>
Ok. And I noted that Richard raised a related question. So I added more
text regarding the nesting of frames in section 2.3.2.3.