Subject: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Nov 2013 17:29:35 +0100

(FYI)

-------- Original Message --------
Subject: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with 
security considerations
Date: Mon, 18 Nov 2013 10:58:46 -0500
From: Moriarty, Kathleen <[email-masked]>
To: [email-masked] <[email-masked]>, [email-masked] <[email-masked]>, 
        [email-masked] 
<[email-masked]>
CC: [email-masked] <[email-masked]>, 
[email-masked] <[email-masked]>

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

Thank you,
Kathleen

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Nov 2013 18:46:36 +0100

Kathleen,

thanks for the feedback.

> IETF LC End Date: End of November

Actually, it was November, 4.

> IESG Telechat date: (if known)

December, 19.

> 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...)?

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

> identify malware or comprised browsers.

See above.

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

> ...

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.

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.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 18 Nov 2013 19:49:32 +0100

On 2013-11-18 19:16, Moriarty, Kathleen wrote:
> Hello Julian,
>
> Responses in-line.
> ________________________________________
> From: Julian Reschke [[email-masked]]
> 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.
>
> 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.

Understood. And we appreciate the feedback; the LC period was really short.

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

I don't believe we'll ever have "complete" security considerations.

That being said: can you clarify what you think needs to be said?

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

Good catch.

The explanation is that P1 and P2 define the basis of the protocol, and 
that's why the other parts point to those Security Considerations.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 19 Nov 2013 13:12:02 +1100

On 19/11/2013, at 4:46 AM, Julian Reschke <[email-masked]> wrote:

> 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 :)

Cheers,

--
Mark Nottingham   http://www.mnot.net/

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 20 Nov 2013 09:37:42 +1100

Hi Kathleen,

Personally - I'm not convinced, because the people who would benefit from that warning are almost certainly not going to be reading this document. 

We're already getting a lot of pushback on the size of our document set; we've often resisted adding advice like this to keep it manageable for implementers N avoid it becoming a "kitchen sink" spec. 

With my chair hat on - what do others think?

Sent from my iPhone

> On 20 Nov 2013, at 3:57 am, "Moriarty, Kathleen" <[email-masked]> wrote:
> 
> Hi Mark & Julian,
> 
> I understand your concerns, but I think a *couple of sentences* could go a long way in terms of awareness of these issues for developers and implementers.  This type of advice is on par with the current security sections added for privacy concerns where you get close to the topic already.  If you read through Section 9.3 and consider predicable information (ID numbers or other distinguishing information whether or not it is PII), it is easy enough to plug in other values into a URI and possibly expose information that should not have been accessible (with a bad configuration - and they do exist).  It would be good to make it clear that this is not a good thing and can be one type of injection attack.
> 
> You are also already covering full path disclosure in 9.1, which is a type of injection attack.
> 
> Julian had requested some text, here are a couple of proposed sentences.
> In the last sentence of the first paragraph, add in 'predicable' to the list  of items at the end of the sentence.  The I suggest adding text along the following lines:
> 
> Injection attacks, such as SQL and full path disclosure should be prevented in URIs to avoid unintended access.  The broader set of injection attacks is out-of-scope for this document, however awareness is important for web developers.  
> 
> OWASP lists injection attacks as the highest risk and defines the more broad set  of injection attacks as follows: 
> Injection flaws, such as SQL, OS, and LDAP injection occur when untrusted data is sent to an interpreter as part of a command or query.  The attacker's hostile data can trick the interpreter into executing unintended commands or accessing data without proper authorization. (Link to OWASP top 10, it is also provided as a PDF if that reference is better: https://www.owasp.org/index.php/Top_10_2013-Top_10)
> ----
> 
> This suggestion is meant to raises awareness and tie into the existing descriptions that get close to this topic.
> 
> Thank you,
> Kathleen
> 
> -----Original Message-----
> From: Mark Nottingham [mailto:[email-masked]] 
> Sent: Monday, November 18, 2013 9:12 PM
> To: Julian Reschke
> Cc: HTTP Working Group; Moriarty, Kathleen
> Subject: Re: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations
> 
> 
>>> 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.
>>

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 20 Nov 2013 13:52:47 +1300

On 2013-11-20 11:37, Mark Nottingham wrote:
> Hi Kathleen,
> 
> Personally - I'm not convinced, because the people who would benefit
> from that warning are almost certainly not going to be reading this
> document.
> 
> We're already getting a lot of pushback on the size of our document
> set; we've often resisted adding advice like this to keep it
> manageable for implementers N avoid it becoming a "kitchen sink" spec.
> 

Good topic for one of the W3C security guideliens for implementation, 
but like already said: in HTTP that data is prety much opaque.

Amos