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

[Tobias Gondrom <[e-mail]>]

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


On 14/08/13 18:51, Ted Lemon wrote:
> 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.
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."

>
>    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].
Ok. I added this line as you suggest.
>    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?

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.]


>
> 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.
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.]


>
> Thanks for documenting this.
>
>