Re: [websec] Sean Turner's Discuss on draft-ietf-websec-x-frame-options-09: (with DISCUSS and COMMENT)

On 14/08/13 17:55, Yoav Nir wrote:
> On Aug 14, 2013, at 7:14 PM, Sean Turner <turners@ieca.com> wrote:
>
>> ----------------------------------------------------------------------
>> DISCUSS:
>> ----------------------------------------------------------------------
>>
>> It's interesting to note that this draft says there's a problem with
>> folks not checking the origins of the entire ancestor tree of names of
>> the framing resource - but then doesn't say that sounds like a good idea
>> do it.  I can see the argument that might be made that this draft is just
>> documenting what's done now, but shouldn't we take the opportunity to do
>> more and recommend something along the lines of "The entire ancestor tree
>> of names of the framing resource SHOULD be checked to mitigate the risk
>> of attacks in multiple-nested scenarios" or something like that?
> The charter mandate was to just document. I think advise to web masters might be in scope, but advise for browser makers (for example, how to harmonize the implementations) is not.
See also my reply to Ted's email.

>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> I'd ask about how RFC 6648 applies to this, but I bet this header was out
>> long before the drafts that lead to RFC 6648.
> 3-4 years before Peter's first draft.
Yes the header was there long before 6648. But we refer to 6648 in the
draft.
>
>> s1 (penultimate paragraph): r/script/Javascript ?
> Any script. Flash can do scripting.
Agree with Yoav. Though the main use case is Javascript. I would suggest
to keep "script" here.

>
>> s4.1: Is Figure 1 missing or is that the registration template? ;)
Yes, Figure 1 is the template. I did it in form of a template to
maintain static formating and xml2rfc generates the "Figure 1" at the
bottom automatically. I guess this can be mitigated by the RFC-Editor
later.

>>
>> s5:
>> r/all kinds of these attack vectors/these kind of attack vectors
>> r/, ...)/)
No. The correction would change the meaning of the sentence.
(to be clear it does help against many of the attack vectors, just not
all...)


>>
>> Appendix A: Is this a guarantee that x-frame-options/frame-options will
>> be supported henceforth until the end of time in those browsers? 
>> Basically, I'm not sure Appendix A is needed.
Obviously it is not a guarantee that x-frame-options shall be supported
henceforth until the end of time. In fact the opposite is true: we hope
that one day it will be replaced by CSP1.1.
However, people in the WG felt it would be good to document the current
use/implementations of X-Frame-Options in this draft (though I don't
remember whether there were any strong opinions on that bit).


>>
>>
>> _______________________________________________
>> websec mailing list
>> websec@ietf.org
>> https://www.ietf.org/mailman/listinfo/websec