W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security considerations

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 18 Nov 2013 19:49:32 +0100
Message-ID: <528A613C.4020409@gmx.de>
To: "Moriarty, Kathleen" <kathleen.moriarty@emc.com>, HTTP Working Group <ietf-http-wg@w3.org>, "gen-art@ietf.org" <gen-art@ietf.org>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-httpbis-p2-semantics.all@tools.ietf.org" <draft-ietf-httpbis-p2-semantics.all@tools.ietf.org>
On 2013-11-18 19:16, Moriarty, Kathleen wrote:
> Hello Julian,
>
> Responses in-line.
> ________________________________________
> From: Julian Reschke [julian.reschke@gmx.de]
> Sent: Monday, November 18, 2013 12:46 PM
> To: HTTP Working Group; Moriarty, Kathleen
> Subject: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24 with security  considerations
>
> Kathleen,
>
> thanks for the feedback.
>
>> Please resolve these comments along with any other Last Call comments
>> you may receive.
>>
>> Document: draft-ietf-httpbis-p2-semantics-24
>> Reviewer: Kathleen Moriarty
>> Review Date: November 18, 2013
>> IETF LC End Date: End of November
>
> Actually, it was November, 4.
>
> KM> I was assigned half of the HTTPbis docs to review in prep for the tele chat, so the timeline may have been longer for the two volunteers who offered to read through all of the documents for you.

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

>> IESG Telechat date: (if known)
>
> December, 19.
>
>> Summary:  The document has a number of run-on sentences that should be
>> fixed.  I also found some security considerations that should be added
>> to the document or referenced in other documents if they have been
>> addressed.
>>
>> Major issues:
>>
>> Minor issues:  Security Considerations
>>
>> Section 9.3:  You may want to include information that informs
>> developers and users of SQL injection attacks.  Fields are still
>> included in some URIs that link you to pages directly that contain
>> personal information using consistent identifiers.  It would be helpful
>> as this is still one of the biggest attack vectors.  A quick search on
>> SQL injection URL will provide additional information for inclusion in
>> the write up.  You mention GET-based forms in section 9.3, but it
>> doesn't mention SQL injection attacks and information in the URIs. Since
>> this is so prevalent still, I think it is important to call out explicitly.
>
> Not convinced. From an HTTP point of view, URIs are just opaque
> identifiers. Also, there are many kinds of injection attacks. Should we
> list them all (XML, javascript...)?
>
> KM> I do think you should mention injection attacks, especially since they are the most common attack method.  Raising awareness with a sentence or two should not be much trouble and would be incomplete without it.

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

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

>> Section 9.4: HTTP User-Agent strings are also used within enterprise at
>> a firewall or by  web servers to prevent the use of outdated browsers,
>> ones with known security issues.  Since this section informs of the
>> negative uses, this one would be important to include to provide a
>> broader picture of how they may be used in a security context.
>
> In
> <http://greenbytes.de/tech/webdav/draft-ietf-httpbis-p2-semantics-25.html#header.user-agent>
> we already say:
>
> "The "User-Agent" header field contains information about the user agent
> originating the request, which is often used by servers to help identify
> the scope of reported interoperability problems, to work around or
> tailor responses to avoid particular user agent limitations, and for
> analytics regarding browser or operating system use."
>
>> User-agent strings are also used in threat detection as there may be a
>> modification to a User-Agent string that helps incident response teams
>> identify malware or comprised browsers.
>
> See above.
> KM> Yes, I read the section and while they are used at the intended receiving server, they are also used at other points in the network.  There may not be awareness of this usage.
>
>> Section 9 should also cover Man-in-the-middle and session hijacking
>> attacks or point to a security consideration section that covers
>> transport security considerations (authentication, encryption, logging,
>> etc.).  If that is covered in another document, please state that and
>> provide a link.  It would be worth including a reference within the
>> introduction of 9 to Part 1 on Messaging Security Considerations,
>> draft-ietf-httpbis-p1-messaging-17 as well.
>
> Transport-related security considerations are on Part 1. I don't believe
> that adding more linking between the parts will make the documents better.
>
> KM> I disagree and the other argument would be for consistency across the set of documents from a Gen-art perspective.  I've only looked at three so far, but 2 of the three reference part 1 and part 2 for security considerations.  Part 2 should also reference part 1.  This reference was at the start of the security considerations section and I recommend that you make this consistent across documents.

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
Received on Monday, 18 November 2013 18:50:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC