Forwarding at Barry's request. Please copy me directly in replies. Sent from my iPhone
Begin forwarded message: > From: Robert Sparks <[email protected]> > Date: August 8, 2013, 3:00:02 PM CDT > To: General Area Review Team <[email protected]>, > [email protected] > Subject: Genart LC review: draft-ietf-websec-x-frame-options-07 > > I am the assigned Gen-ART reviewer for this draft. For background on > Gen-ART, please see the FAQ at > > <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>. > > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-websec-x-frame-options-07 > Reviewer: Robert Sparks > Review Date: 2013-08-08 > IETF LC End Date: 2013-08-12 > IESG Telechat date: 2013-08-15 > > Summary: This draft is basically ready for publication, but has nits that > should be fixed before publication. > > This document is intended to act as a informational reference describing > what's already deployed, and not to act as a standard for new implementations > to follow. It's obvious that some care has been taken to keep that tone in > the text, but there are places where it still looks like a proposed standard. > Please make it even more clear who the audience for this document is, and > look for places to reinforce that this is documenting what _is_, as opposed > to trying to influence what should be. > > The introduction of this version of the document does a good job of > describing what a clickjack attack is. Appendix B is not really adding to > that description. I suggest that the two usecases it call out be reduced to a > couple of sentences in the introduction as examples, and a reference to a > more in-depth treatment of scenarios like them be added for those looking for > more information. Section B.3 is different, and doesn't add to the > understanding of this document. Again, I suggest pointing to somewhere else > that provides an in-depth treatment. (Hopefully, that source would discuss > the nested frame issue the security considerations section points out in the > context of the this specific configuration page). [FRAME-BUSTING] might be > enough, but pointers to something even more rich would certainly be helpful. > > Here are some suggestions in document order: > > In the Abstract, I suggest replace "specification" with either "definition" > as the introduction uses, or with "the syntax and behavior observed in > current deployments". > > The last paragraph of the introduction reads like standards text. Please > consider rewriting it with a tone of history and current fact. Perhaps > starting with "In existing implementations, ", and replacing the last > sentence with something like "The policy this HTTP header declares is > enforced by the browser implementations documented here". > > Since this is documenting an existing deployed header (not standardizing it), > it would be useful to comment whether the existing known implementations > allow all the productions of the ABNF described here to be used. For > instance, would they all honor X-FRAME-OPTIONS: deny? (While thinking about > this, focus on who this document is for.) > > The last sentence of 2.3.1 as written is an attempt to be a standard, and is > an odd use of 2119. I suggest rewriting it as a warning about what happens > with existing plugins that ignore the policy carrid in the header. That keeps > the message aligned with documenting what exists. > > The first sentence of 2.3.2 is not adding anything to the document. I suggest > deleting it. The second sentence is placing an implementation requirement > again. Please consider rewriting as an observation of what existing things > do, calling out the ramifications of the ones that behave differently. > > Similarly, the first paragraphs of Section 2.3.2.1 is written to affect new > implementation, not document existing implementation. They could be re-tuned > as above. The third paragraph is good history > > The last sentence of 2.3.2.2 should not say "replace this document" - this > document is informational documentation about existing deployments. CSP1.1 > won't Obsolete or Replace this document. Rather it should say something like > "it is expected that newer implementations will use it rather than the > mechanisms documented here". > > Nit: s/does support only one/only supports one/ > > Do the known implementations follow the pattern described in 2.3.2.3? Saying > something would help tie this to being information about the known deployment > rather than trying to constrain new development. > > Nit: If Appendix B is kept, please expand CSRF (and consider re-pointing to a > reference) >
_______________________________________________ websec mailing list [email protected] https://www.ietf.org/mailman/listinfo/websec
