Re: [apps-discuss] Appsdir review of draft-ietf-websec-x-frame-options-06

Martin Thomson <martin.thomson@gmail.com> Mon, 29 July 2013 11:24 UTC

MIME-Version: 1.0
In-Reply-To: <CABkgnnVkxNFUJ5=dEmrooAS0-aqSxk=GLQvxPTtdSuT1uvrW9g@mail.gmail.com>
References: <CABkgnnVkxNFUJ5=dEmrooAS0-aqSxk=GLQvxPTtdSuT1uvrW9g@mail.gmail.com>
Date: Mon, 29 Jul 2013 04:24:04 -0700
Message-ID: <CABkgnnXcnekbCu7Hj4V7tnmetiK1d4goX_4Mk70X-C=J9p0Guw@mail.gmail.com>
From: Martin Thomson <martin.thomson@gmail.com>
To: IETF Apps Discuss <apps-discuss@ietf.org>, draft-ietf-websec-x-frame-options.all@tools.ietf.org
Content-Type: text/plain; charset="UTF-8"
Cc: The IESG <iesg@ietf.org>
Subject: Re: [apps-discuss] Appsdir review of draft-ietf-websec-x-frame-options-06
Precedence: list

I can never get the addresses right on these things.  Adding
draft-related recipients.

On 29 July 2013 02:37, Martin Thomson <martin.thomson@gmail.com> wrote:
> I have been selected as the Applications Area Directorate reviewer for
> this draft (for background on appsdir, please see
> http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate
> ).
>
> Please resolve these comments along with any other Last Call comments
> you may receive. Please wait for direction from your document shepherd
> or AD before posting a new version of the draft.
>
> Document: draft-ietf-websec-x-frame-options-06
> Title: HTTP Header Field X-Frame-Options
> Reviewer: Martin Thomson
> Review Date: 2013-07-29
> IETF Last Call Date: ?
> IESG Telechat Date: ?
>
> Summary:
> This draft is almost ready for publication as an Informational RFC.
>
> Major Issues:
>
> Please make the list of affected contexts explicit from the outset.
> The draft initally only talks about <frame> and <iframe>.  And then
> Section 2.3.1 comes around and causes me to become highly confused.
> At first read, I thought that 2.3.1 just wasn't clear enough about the
> fact that addressing only frames and iframes is a problem.  On a
> second read, it seems to imply that X-Frame-Options is intended to
> apply to cross-origin content of the identified forms _in addition to_
> frame and iframe.
>
> 2.3.2.1 says "the browser SHOULD redirect as soon as possible to a
> "No-Frame" page".  I don't know how to do that based on the current
> text.  Where does the redirect happen, what does it redirect to,
> etc...  I think that the intent is to say that "In place of the framed
> content, the browser SHOULD render placeholder content that informs
> the user that the intended content could not be framed.  It MAY
> include a link that opens the content in an unframed context."
>
> Minor Issues:
>
> The definition of ALLOW-FROM says that it is followed by "a URI [...]
> of a trusted origin".  I was initially inclined to suggest that this
> be restricted to the origin serialization defined in Section 6.1 of
> RFC6454, but it's clear that existing implementations accept URIs.
> (And an origin happens to also be a valid URI, so that's good.)  I
> think that this description could be clearer.  In particular, the fact
> that port numbers are ignored is really important, but it's almost
> hidden.
>
> Perhaps a reword:
>
>    ALLOW-FROM  (followed by a URI [RFC3986])
>          A browser receiving content with this header MUST NOT display
>          this content in a frame from any page with a top-level browsing
>          context that has a different scheme or host from the identified URI.
>
>          This uses a limited two-tuple form of the web origin concept [RFC6454].
>          All parts of the URI aside from scheme and host are ignored.
>
> This is perhaps a change, because it defines the behavior of existing
> implementations, but I believe that this is consistent with the intent
> of the document.
>
> Did 2.3.1 this omit other forms of content inclusion intentionally
> (IMG, SCRIPT, VIDEO, AUDIO, etc..)?  Can this be explained better?
>
> The meta http-equiv thing is a bit of a big deal.  I'm surprised that
> it's hidden in the last paragraph of security considerations.  Since
> this is in some views a property of content, not supporting http-equiv
> is a large gotcha.  Please consider highlighting it.
>
> Nits:
> Introduction: s/Thus, Thus, /Thus, /

[apps-discuss] Appsdir review of draft-ietf-webse… Martin Thomson
Re: [apps-discuss] Appsdir review of draft-ietf-w… Martin Thomson