Subject: [websec] Ted Lemon's No Objection on draft-ietf-websec-x-frame-options-09: (with COMMENT)

From: "Ted Lemon" <[email-masked]>
Date: Wed, 14 Aug 2013 10:51:21 -0700

Ted Lemon has entered the following ballot position for
draft-ietf-websec-x-frame-options-09: 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:
----------------------------------------------------------------------

The introduction of the concept of origins in 2.1 is a bit clumsy—the
term is used under the SAMEORIGIN heading without being defined, and is
later defined as a constraint specific only to ALLOW-FROM.   Text about
browser implementations for SAMEORIGIN and ALLOW-FROM is repeated here
and in later sections.   It would be better to simply refer to the later
section.   If I were to clean up this section, I would do something like
the following:

DENY
         A browser receiving content with this header MUST NOT display
         this content in any frame.

   SAMEORIGIN
         A browser receiving content with this header field MUST NOT
         display this content in any frame from a page of different
         origin than the content itself.
         If a browser or plugin can not reliably determine whether the
         origin of the content and the frame have the same origin, this
         MUST be treated as "DENY".   Section 2.3.2.2 documents
         variations in the handling of this header field by different
         browsers.

   ALLOW-FROM  (followed by a URI [RFC3986] of a trusted origin)
         A browser receiving content with this header MUST NOT display
         this content in a frame from any page with a top-level browsing
         context of different origin than the specified origin.  While
         this can expose the page to risks by the trusted origin, in
         some cases it may be necessary to allow the framing by content
         from other domains.

   The meaning of the term "origin" is given in [RFC6454].
   If the ALLOW-FROM value is used, it MUST be followed by a valid URI.
   Any data beyond the domain address (i.e.  any data after the "/"
   separator) is to be ignored.  And the algorithm to compare origins
   from [RFC6454] SHOULD be used to verify that a referring page is of
   the same origin as the content or that the referring page's origin is
   identical with the ALLOW-FROM URI.  Though in conflict with
   [RFC6454], current implementations do not consider the port as a
   defining component of the origin.

I also noticed that in another exchange about this document, someone said
that this document is not intended to give advice to browser vendors.  
If that's the case, what is the above SHOULD doing in the text?   Is
there uncertainty as to what implementations do?   If so, it would be
better to express that uncertainty, if indeed you are documenting browser
behavior.

Also, with respect to this text:

   Though in conflict with
   [RFC6454], current implementations do not consider the port as a
   defining component of the origin.

Does this mean that http://www.foo.com and http://www.foo.com:8080 are
considered equivalent, or that http://www.foo.com and
http://www.foo.com:80 are _not_ considered equivalent?   What about
http://www.foo.com and https://www.foo.com?

The following text is incomprehensible to me as a non-domain-expert:

   The criteria for the SAMEORIGIN option is not evaluated unanimously
   either: one implementation may evaluate the SAMEORIGIN option based
   on the origin of the framed page and the framing page, while another
   may evaluate based on the framed page and the top-level browsing-
   context.

What is the distinction between "top-level browsing context" and "origin
of the framing page?"   A reference here would be helpful.

Thanks for documenting this.

---

From: Tobias Gondrom <[email-masked]>
Date: Wed, 14 Aug 2013 22:07:55 +0100

Hi Ted,
thanks for the review and your comments.
Answers inline.
I included your feedback comments in version-10 as outlined below (which
I hold back for one day as the changes are not material and I like to
combine them with other potentially upcoming feedback)
Thanks for the review and all the best, Tobias
Best regards, Tobias

> http://datatracker.ietf.org/doc/draft-ietf-websec-x-frame-options/
Hm. I see your point.
My solution would be close to your suggestion:
(But not to remove the text before about the variations in implementations)
and add the following text at the end:
"See also section 2.3.2.2 documents variations in the handling of this
header field by different browsers."

>    The meaning of the term "origin" is given in [RFC6454].
Ok. I added this line as you suggest.
> http://www.foo.com and https://www.foo.com?

As outline in RFC6454, origin identity is defined by the triplet
protocol, address and port. If all three are identical, the origin is
the same, otherwise not.
As written in the draft, current implementations do not consider the
port as a defining component of the origin, this means that only
protocol and address are defining criteria, i.e. http://www.foo.com:8080
and http://www.foo.com are read as from the same origin. (and
http://www.foo.com and https://www.foo.com are _not_ same origin)

I had the hope with referring to RFC6454 this should be unambiguous and
clear enough. I had the hesitation to write redundant text, but maybe I
got too short. Do you think we need to spell it out more explicitly in
the draft so people understand?

[will keep the text as is until I hear an argument that this is indeed
not clear enough yet.]

> of the framing page?"   A reference here would be helpful.
Apologies. In this case I have hesitations to add an explanation about
the nesting of frames in html. In general the concept of nested frames
(and top-level vs. framing page) is reasonably understood.
[will keep the text as is until I hear an argument that this really
needs an explanation in this draft.]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 14 Aug 2013 17:49:25 -0400

> the draft so people understand?

How about:

  Existing implementations differ with [RFC6454] in that origins with
  the same protocol but different port values are considered equivalent.

> needs an explanation in this draft.]

The additional text that you added in your reply helps a little—it appears that "top-level browsing context" means "the HTML that is loaded first and that contains whatever nesting might occur" and perhaps that "origin of the framing page" refers somehow to the idea of nested frames.   But even with the help you've given me in your reply, I am not sure that I have this right, and indeed I am scratching my head trying to figure out what the difference is between these two contexts.

As a person who writes HTML fairly regularly, I think I am your intended target audience.   If so, you really do need to explain what these terms mean, or provide a reference to a document that explains them.

---

From: Tobias Gondrom <[email-masked]>
Date: Sat, 17 Aug 2013 23:45:31 +0100

>   the same protocol but different port values are considered equivalent.
Ok. I added the sentence you suggested in version-10 as:
"I.e. existing implementations differ with [RFC6454] in that origins
with the same protocol but different port values are considered equivalent."

> As a person who writes HTML fairly regularly, I think I am your intended target audience.   If so, you really do need to explain what these terms mean, or provide a reference to a document that exp…
Ok. And I noted that Richard raised a related question. So I added more
text regarding the nesting of frames in section 2.3.2.3.