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

#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 18:46:36 +0100
Message-ID: <528A527C.4000809@gmx.de>
To: HTTP Working Group <ietf-http-wg@w3.org>, "Moriarty, Kathleen" <kathleen.moriarty@emc.com>
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.

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

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

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

> Nits/editorial comments:
> ...

Regarding "ought vs SHOULD": we've received feedback telling us to use 
*more* normative keywords. We have also received feedback telling us to 
use *less*. We have decided to leave things alone, and tune things in 
case the IESG comes up with concrete suggestions and guidelines.

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
Received on Monday, 18 November 2013 17:47:06 UTC

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