Hello Julian, Responses in-line. ________________________________________ From: Julian Reschke [julian.resc...@gmx.de] Sent: Monday, November 18, 2013 12:46 PM To: HTTP Working Group; Moriarty, Kathleen Subject: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations
Kathleen, thanks for the feedback. > Please resolve these comments along with any other Last Call comments > you may receive. > > Document: draft-ietf-httpbis-p2-semantics-24 > Reviewer: Kathleen Moriarty > Review Date: November 18, 2013 > IETF LC End Date: End of November Actually, it was November, 4. KM> I was assigned half of the HTTPbis docs to review in prep for the tele chat, so the timeline may have been longer for the two volunteers who offered to read through all of the documents for you. > IESG Telechat date: (if known) December, 19. > Summary: The document has a number of run-on sentences that should be > fixed. I also found some security considerations that should be added > to the document or referenced in other documents if they have been > addressed. > > Major issues: > > Minor issues: Security Considerations > > Section 9.3: You may want to include information that informs > developers and users of SQL injection attacks. Fields are still > included in some URIs that link you to pages directly that contain > personal information using consistent identifiers. It would be helpful > as this is still one of the biggest attack vectors. A quick search on > SQL injection URL will provide additional information for inclusion in > the write up. You mention GET-based forms in section 9.3, but it > doesn't mention SQL injection attacks and information in the URIs. Since > this is so prevalent still, I think it is important to call out explicitly. Not convinced. From an HTTP point of view, URIs are just opaque identifiers. Also, there are many kinds of injection attacks. Should we list them all (XML, javascript...)? KM> I do think you should mention injection attacks, especially since they are the most common attack method. Raising awareness with a sentence or two should not be much trouble and would be incomplete without it. > Section 9.4: HTTP User-Agent strings are also used within enterprise at > a firewall or by web servers to prevent the use of outdated browsers, > ones with known security issues. Since this section informs of the > negative uses, this one would be important to include to provide a > broader picture of how they may be used in a security context. In <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#header.user-agent> we already say: "The "User-Agent" header field contains information about the user agent originating the request, which is often used by servers to help identify the scope of reported interoperability problems, to work around or tailor responses to avoid particular user agent limitations, and for analytics regarding browser or operating system use." > User-agent strings are also used in threat detection as there may be a > modification to a User-Agent string that helps incident response teams > identify malware or comprised browsers. See above. KM> Yes, I read the section and while they are used at the intended receiving server, they are also used at other points in the network. There may not be awareness of this usage. > Section 9 should also cover Man-in-the-middle and session hijacking > attacks or point to a security consideration section that covers > transport security considerations (authentication, encryption, logging, > etc.). If that is covered in another document, please state that and > provide a link. It would be worth including a reference within the > introduction of 9 to Part 1 on Messaging Security Considerations, > draft-ietf-httpbis-p1-messaging-17 as well. Transport-related security considerations are on Part 1. I don't believe that adding more linking between the parts will make the documents better. KM> I disagree and the other argument would be for consistency across the set of documents from a Gen-art perspective. I've only looked at three so far, but 2 of the three reference part 1 and part 2 for security considerations. Part 2 should also reference part 1. This reference was at the start of the security considerations section and I recommend that you make this consistent across documents. > Nits/editorial comments: > ... Regarding "ought vs SHOULD": we've received feedback telling us to use *more* normative keywords. We have also received feedback telling us to use *less*. We have decided to leave things alone, and tune things in case the IESG comes up with concrete suggestions and guidelines. KM> I'll leave this up to Jari. I made a point of only calling out a few of the uses of ought where I thought the change would be helpful to the reader (developer, implementor, etc.) Regarding the other editorial comments: we are past three WG and one IETF Last Call. At this point, I'd prefer not to rephrase anything unless it's clearly incorrect or misleading. KM> This may increase the time it takes to get the document through the RFC editor. The review and assistance with grammar and issues like run-on sentences are intended to be a helpful service to document editors to speed up the publication process addressing nits early. Best regards, Kathleen Best regards, Julian _______________________________________________ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
