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

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jul 2013 02:37:27 -0700

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, /

---

From: Martin Thomson <[email-masked]>
Date: Mon, 29 Jul 2013 04:24:04 -0700

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