Last Call Review of draft-ietf-websec-x-frame-options-07
review-ietf-websec-x-frame-options-07-secdir-lc-salowey-2013-08-16-00

Do not be alarmed. I have reviewed this document as part of the security
directorate's ongoing effort to review all IETF documents being processed by
the IESG.  These comments were written primarily for the benefit of the
security area directors.  Document editors and WG chairs should treat these
comments just like any other last call comments.

This document is ready with issues.

The document is generally well written and covers an important topic. It
describes existing options that can be included in an HTTP header to to prevent
the HTTP content from being embedded in the frame of another page.   The
document describes the existing options and therefore meets its main goal.    
The main issue I see with the document is in the lack of guidance on  when to
use the options.

Issues:

1.  Section 2.1: It seems that  RFC6454 should be first referenced in the
SAMEORIGIN section.   Also, shouldn't the note about port not considered as a
defining component of origin apply to SAMEORIGIN as well?

2.  Section 2.3.1: I'm not sure what section 2.3.1 is trying to say.    Is it
saying that the X-FRAME-OPTIONS should apply to all of these embedding
mechanisms?   If this is the case then I think this section should explicitly
say so.

3.  Section 5:

- The security considerations states that the X-FRAME-OPTIONS "it is not
self-sufficient on its own, but must be used in conjunction with other security
measures like secure coding and the Content Security Policy."  This statement
leads me to believe that more guidance is necessary.  For example, does the
reference to "secure coding" a general statement, or are there specific coding
considerations that are specific to clickjacking protection?   If its general
then it doesn't really add anything so I think it would be better to be more
specific.   The same comment applies to CSP.

- Should pages also employ framebusting since the header options are not
uniformly implemented?

- Perhaps the second paragraph should explicitly say that because of this
developers must be aware that embedding content from other sites may leave them
vulnerable to clickjacking if the SAMEORIGIN directive is used.

- What pages should include this header option?   More guidance here would be
good.  Right now its necessarily clear which pages should include this header
especially given the uncertainty with SAMEORIGIN described in the second
paragraph.  Should all pages on a site deny being framed unless their content
needs to be embedded in another site?