Subject: [websec] WGLC for X-Frame-Options

From: Yoav Nir <[email-masked]>
Date: Wed, 24 Oct 2012 00:39:45 +0200

Hi all

This is to initiate WGLC for the X-Frame-Options draft (not to be confused with the Frame-Options draft).

Please go to http://tools.ietf.org/html/draft-ietf-websec-x-frame-options-01, read the draft and send comments.

As usual, we would very much like to hear comments about clarity, thoroughness and applicability. Since this draft documents existing behavior, rather than prescribing future behavior, we would especially like to hear from people familiar with current implementations that support the X-Frame-Option header about whether the draft accurately describes the behavior of those implementations.

WGLC is usually for two weeks. However, the following two weeks include an IETF meeting, so I am extending this period to a little over three weeks. WGLC will end on Friday, November 16th. Please send your comments early, so that we might use our session in Atlanta to discuss issues that come up.

Yoav

---

From: Yoav Nir <[email-masked]>
Date: Wed, 31 Oct 2012 10:04:43 +0200

Hi all

Don't forget to review and comment the X-Frame-Options draft.

Here's my review (no hats)

Informational documents do not specify standards. The boilerplate says so:
   This document is not an Internet Standards Track specification; it is
   published for informational purposes.

 I suggest in the abstract changing "... this standard defines" to "... this document describes"

The abstract is a little hard to read. Suggested text:
OLD:
   To improve the protection of web applications against Clickjacking
   this standard defines an http response header that declares a policy
   communicated from a host to the client browser on whether the browser
   must not display the transmitted content in frames of other web
   pages.  This drafts serves to document the existing use and
   specification of X-Frame-Options.
NEW:
   To improve the protection of web applications against Clickjacking,
   this document describes an http response header that declares a policy
   communicated from the server to the client browser on whether the browser
   may display the transmitted content in frames that are part of other web
   pages.  This drafts serves to document the existing use and
   specification of X-Frame-Options.

Section 1: the draft is not going to be replaced, but hopefully, the header is. 
OLD:
                                                 This draft is to
   document the current use of X-Frame-Options header and shall in the
   future be replaced by the Frame-Options [FRAME-OPTIONS] standard.
NEW:
                                                 This draft documents
   the current use of the X-Frame-Options header, which shall in the
   future be replaced by the Frame-Options [FRAME-OPTIONS] standards-
   based header.

Section 2. I don't think you should have a MUST NOT after 'whether'. Also, the capitalization seems to indicate normative language, while what you are actually describing are the semantics of the header.
OLD:
   The X-Frame-Options HTTP response header indicates a policy whether a
   browser MUST NOT allow to render a page in a <frame> or <iframe> .
   Hosts can declare this policy in the header of their HTTP responses
   to prevent clickjacking attacks, by ensuring that their content is
   not embedded into other pages or frames.
NEW:
   The X-Frame-Options HTTP response header indicates a policy on 
   whether the browser should render the transmitted resource within a 
   <frame> or <iframe>. Servers can declare this policy in the header of 
   their HTTP responses to prevent clickjacking attacks, by ensuring 
   that their content is not embedded into other pages or frames.
   
Section 2.1: s/NOT more than one of the three values MUST be/exactly one of the three values MUST be/
Also, to avoid the line break in the middle of the example header, please break after "For example:" under ALLOW_FROM

Section 2.2: I think you're defining "Frame-Options". Don't forget the "X-" on the right side of the equals sign.

RFC 822 has been obsoleted twice. The latest is 5322, although the actual syntax is in 5234, so maybe that's the one you should reference.

Yoav