Subject: [websec] Spencer Dawkins' No Objection on draft-ietf-websec-x-frame-options-08: (with COMMENT)

From: "Spencer Dawkins" <[email-masked]>
Date: Mon, 12 Aug 2013 18:10:10 -0700

Spencer Dawkins has entered the following ballot position for
draft-ietf-websec-x-frame-options-08: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to http://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

I really like this specification, and I appreciate the working group
producing it. Documenting "in the wild" behavior is a good thing.

I have one fairly fundamental comment, which I think can be easily
addressed, and a few nits.

My comment: This specification starts out like a normal header field
specification until you get to 

1.  Introduction

   This specification provides informational documentation about the
   current use and definition of the X-Frame-Options HTTP header field.
   Given that the "X-" construction is deprecated [RFC6648], the X
   -Frame-Options header field will in the future be replaced by the
   Frame-Options directive in the Content Security Policy Version 1.1
   [CSP-1-1]. 

That's still KIND of OK (no indication that anything is wrong with
X-FRAME-OPTIONS functionality, just a heads-up that implementations that
include X-FRAME-OPTIONS will have work to do in the future), but when we
get to 

2.3.2.2.  Variation in current browser behaviour

   There are currently variations in the implementation of the X-FRAME-
   OPTIONS header. 

we discover unambiguously that current implmentations don't all work the
same way, so your ability to rely on X-FRAME-OPTIONS is not entirely
clear.

I wonder if the set of technical details are asperational, saying "this
is what X-FRAME-OPTIONS could have been, and what the next header field
in this space should be".

I think it's fine to publish this specification, especially as
Informational, even if it's not clear to me that *any* of the
functionality described in this specification is implemented the same way
in all major browsers.

I would be more comfortable with a clear statement in the Introduction
that the biggest problem with X-FRAME-OPTIONS is *not* the leading "X-",
but that today's implementations don't all provide the same options with
the same behaviors, so relying on this specification as a predictor of
what will happen to your frames is not a good idea. 

One sentence that puts the reader on notice would be sufficient.

My nits, just so editors don't have to find them again:

Is there a reason why sometimes X-FRAME-OPTIONS is in all caps, and other
times not? I'm not an APP guy, so I'm asking.

In Section 2.3.2.2.  Variation in current browser behaviour

   These variations in the evaluation of the header by different
   implementations impair the useage and reliability of this http
   header.  A revised version of x-frame-options in the form of a frame-
   options directive in the CSP 1.1[CSP-1-1] will unify the behaviour
   and it is expected that newer implementations will use it rather than
   the mechanisms documented here"

The trailing quote mark should be a period, I suppose?

5.1.  Privacy Considreations should be "Considerations".

In B.2.  Online Shop Confirm Purchase Page

   The "Confirm Purchase"" 

The doubled trailing quote marks should be one quote mark, perhaps?

---

From: Tobias Gondrom <[email-masked]>
Date: Tue, 13 Aug 2013 17:47:32 +0100

Dear Spencer,
thanks a lot for the review and feedback.
I included your feedback comments in version-09.
Thanks for the review and all the best, Tobias

> http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/
Done.

> times not? I'm not an APP guy, so I'm asking.
Only reason is that my eyes got tired of so many all caps in the flow
text, while in some place, I felt it would be easier to read when in all
caps. Both are possible.

> The trailing quote mark should be a period, I suppose?
Yes. Corrected.

> 5.1.  Privacy Considreations should be "Considerations".
Thanks. Corrected.
> The doubled trailing quote marks should be one quote mark, perhaps?
Yes. Thanks. Corrected.