mnot
commented
10 years ago - julian.reschke@gmx.de changed milestone from
unassignedto26 - julian.reschke@gmx.de changed severity from
In IETF LCtoIn IESG Evaluation
Closed mnot closed 3 years ago
mnot
commented
10 years ago unassigned to 26In IETF LC to In IESG Evaluationmnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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.
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via" HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from: An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF. To: An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence: In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request. How about this instead: In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
to:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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.
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
mnot
commented
10 years ago Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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.
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
to:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that'' -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
design to editorialmnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that'' -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
to:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
to:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.(Formatting issue that already has been fixed)
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
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.
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.
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.(Formatting issue that already has been fixed)
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
to:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
~~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. ~~
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.Jari: On the Section 9.4 issue I understand the raised concern, but reading the text I think the current text is fine. http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1898.html
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.(Formatting issue that already has been fixed)
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
mnot
commented
10 years ago julian.reschke@gmx.de commented:
From 2536:
add link to P1 security considerations (see #520)
mnot
commented
10 years ago julian.reschke@gmx.de changed description from:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
~~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. ~~
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.Jari: On the Section 9.4 issue I understand the raised concern, but reading the text I think the current text is fine. http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1898.html
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.
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.(Formatting issue that already has been fixed)
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
to:
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
~~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. ~~
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.Jari: On the Section 9.4 issue I understand the raised concern, but reading the text I think the current text is fine. http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1898.html
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.- see 2536
Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.(Formatting issue that already has been fixed)
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
mnot
commented
10 years ago I just had another look at the remaining editorial suggestions provided in the review, and I don't think any changes are required nor useful.
incorporatednew to closedmnot
commented
10 years ago fielding@gbiv.com commented:
From 2565:
(editorial) Add security section on injection attacks; reference the OWASP Guide instead of the wiki; see #520 and #549
mnot
commented
10 years ago fielding@gbiv.com commented:
From 2567:
(editorial) Use more specific headers in security section for clarity and put related sections next to each other; see #520 and #549
mnot
commented
10 years ago fielding@gbiv.com commented:
From 2568:
(editorial) update security section intro for p7; see #520 and #549
mnot
commented
10 years ago fielding@gbiv.com commented:
From 2569:
(editorial) OWASP only provides useful additional info for web application semantics and authentication; see #520 and #549
Document: draft-ietf-httpbis-p2-semantics-24 Reviewer: Kathleen Moriarty Review Date: November 18, 2013 IETF LC End Date: End of November IESG Telechat date: (if known)
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...)?
+1 - SQL doesn't have anything to do with HTTP, and even though it is used often in conjunction with the protocol, it's an implementation-specific choice.
For example, I don't use any SQL on my Web site, and am very happy about that -- see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1154.html
~~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. ~~
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.Jari: On the Section 9.4 issue I understand the raised concern, but reading the text I think the current text is fine. http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/1898.html
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.- see 2536Nits/editorial comments:
Section 1, second sentence: No comma necessary before "via"
HTTP provides a uniform interface for interacting with a resource (Section 2), regardless of its type, nature, or implementation via the manipulation and transfer of representations
Section 3, paragraph 1, consider breaking the first sentence into two.
Second paragraph, break into multiple sentences.
Section 3.1.1.3: Remove unnecessary comma after parse, change from:
An HTTP sender MAY generate, and a recipient MUST be able to parse, line breaks in text media that consist of CRLF, bare CR, or bare LF.
To:
An HTTP sender MAY generate, and a recipient MUST be able to parse line breaks in text media that consist of CRLF, bare CR, or bare LF.
Section 3.1.4.1 Break #4 down into multiple sentences or a structure that is easier to parse.
Section 3.1.4.2: Several sentences are way too long, please consider breaking them into multiple sentences.
Section 3.3, paragraph 2, Break the second sentence into multiple sentences. This could be listed as two examples without the comparison statement.
Section 3.4, last sentence, While I appreciate the reference and found it humorous, this reference may not be easily understood by an international audience. I suggest that you explain the recommendation in plain text, followed by the reference to reach all audiences.
Section 3.4.1, please break the last sentence into multiple sentences.
Section 3.4.2, please break the second to last paragraph into multiple sentences.
Section 4 starts using the word ought. SHOULD would be more appropriate if that is what is intended as the statements refer to IANA actions and would be better read with well-defined terms.
Section 4.2.2, please break the second to last sentence into multiple sentences.
Section 4.3.4, several run-on sentences should be broken into multiple sentences.
Section 4.3.5, please break the 3rd to last paragraph into multiple sentences.
Second to last and the last paragraph on page 35 should be broken into multiple sentences.
Note at end of page 38 should be broken into multiple sentences.
Last sentence on page 42 should be broken into multiple sentences.
Section 6.3.1, remove carriage return after "The" in first line.(Formatting issue that already has been fixed)
Last sentence of page 53, please break into multiple sentences.
6.4.1. First sentence should be broken into a couple.
6.4.4 Use of word 'ought' sounds odd in this sentence:
In order to satisfy the original request, a user agent ought to perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
How about this instead:
In order to satisfy the original request, a user agent can perform a retrieval request using the Location URI (a GET or HEAD request if using HTTP), which can itself be redirected further, and present the eventual result as an answer to the original request.
Section 7.1.4: Please break the first sentence of the second and last paragraphs into multiple sentences.
Section 9.6 has a few run-on sentences, please break them up -- First sentence of 4th paragraph for instance.
Last paragraph: I'd like to see a SHOULD in the first sentence to make this stronger, otherwise, there is no hope it will happen. I'm not even sure how the user could be informed of loss of privacy considerations if it is not built in, this is a tough approach and I don't see it being effective for most users. If this is configurable at the time of browser installation, would you recommend that there is a series of prompts that inform the user about each choice or did you have something else in mind? An example may help here to actually see something happen as a result of the recommendation.
Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/520