Skip to main content

Last Call Review of draft-ietf-websec-x-frame-options-07

Request Review of draft-ietf-websec-x-frame-options
Requested revision No specific revision (document currently at 12)
Type Last Call Review
Team General Area Review Team (Gen-ART) (genart)
Deadline 2013-08-12
Requested 2013-08-08
Authors David Ross, Tobias Gondrom
I-D last updated 2013-08-08
Completed reviews Genart Last Call review of -07 by Robert Sparks (diff)
Genart Last Call review of -07 by Robert Sparks (diff)
Secdir Last Call review of -07 by Joseph A. Salowey (diff)
Assignment Reviewer Robert Sparks
State Completed
Request Last Call review on draft-ietf-websec-x-frame-options by General Area Review Team (Gen-ART) Assigned
Reviewed revision 07 (document currently at 12)
Result Ready w/nits
Completed 2013-08-08
I am the assigned Gen-ART reviewer for this draft. For background on
Gen-ART, please see the FAQ at


Please resolve these comments along with any other Last Call comments
you may receive.

Document: draft-ietf-websec-x-frame-options-07
Reviewer: Robert Sparks
Review Date: 2013-08-08
IETF LC End Date: 2013-08-12
IESG Telechat date: 2013-08-15

Summary: This draft is basically ready for publication, but has nits 

that should be fixed before publication.

This document is intended to act as a informational reference describing 

what's already deployed, and not to act as a standard for new 

implementations to follow. It's obvious that some care has been taken to 

keep that tone in the text, but there are places where it still looks 

like a proposed standard. Please make it even more clear who the 

audience for this document is, and look for places to reinforce that 

this is documenting what _is_, as opposed to trying to influence what 

should be.

The introduction of this version of the document does a good job of 

describing what a clickjack attack is. Appendix B is not really adding 

to that description. I suggest that the two usecases it call out be 

reduced to a couple of sentences in the introduction as examples, and a 

reference to a more in-depth treatment of scenarios like them be added 

for those looking for more information. Section B.3 is different, and 

doesn't add to the understanding of this document. Again, I suggest 

pointing to somewhere else that provides an in-depth treatment. 

(Hopefully, that source would discuss the nested frame issue the 

security considerations section points out in the context of the this 

specific configuration page). [FRAME-BUSTING] might be enough, but 

pointers to something even more rich would certainly be helpful.

Here are some suggestions in document order:

In the Abstract, I suggest replace "specification" with either 

"definition" as the introduction uses, or with "the syntax and behavior 

observed in current deployments".

The last paragraph of the introduction reads like standards text. Please 

consider rewriting it with a tone of history and current fact. Perhaps 

starting with "In existing implementations, ", and replacing the last 

sentence with something like "The policy this HTTP header declares is 

enforced by the browser implementations documented here".

Since this is documenting an existing deployed header (not standardizing 

it), it would be useful to comment whether the existing known 

implementations allow all the productions of the ABNF described here to 

be used. For instance, would they all honor X-FRAME-OPTIONS: deny? 

(While thinking about this, focus on who this document is for.)

The last sentence of 2.3.1 as written is an attempt to be a standard, 

and is an odd use of 2119. I suggest rewriting it as a warning about 

what happens with existing plugins that ignore the policy carrid in the 

header. That keeps the message aligned with documenting what exists.

The first sentence of 2.3.2 is not adding anything to the document. I 

suggest deleting it. The second sentence is placing an implementation 

requirement again. Please consider rewriting as an observation of what 

existing things do, calling out the ramifications of the ones that 

behave differently.

Similarly, the first paragraphs of Section is written to affect 

new implementation, not document existing implementation. They could be 

re-tuned as above. The third paragraph is good history

The last sentence of should not say "replace this document" - 

this document is informational documentation about existing deployments. 

CSP1.1 won't Obsolete or Replace this document. Rather it should say 

something like "it is expected that newer implementations will use it 

rather than the mechanisms documented here".

Nit: s/does support only one/only supports one/

Do the known implementations follow the pattern described in 

Saying something would help tie this to being information about the 

known deployment rather than trying to constrain new development.

Nit: If Appendix B is kept, please expand CSRF (and consider re-pointing 

to a reference)