On 2013-11-18 19:16, Moriarty, Kathleen wrote:
Hello Julian,
Responses in-line.
________________________________________
From: Julian Reschke [julian.resc...@gmx.de]
Sent: Monday, November 18, 2013 12:46 PM
To: HTTP Working Group; Moriarty, Kathleen
Subject: #520, was: Fwd: Gen-Art review of draft-ietf-httpbis-p2-semantics-24
with security considerations
Kathleen,
thanks for the feedback.
Please resolve these comments along with any other Last Call comments
you may receive.
Document: draft-ietf-httpbis-p2-semantics-24
Reviewer: Kathleen Moriarty
Review Date: November 18, 2013
IETF LC End Date: End of November
Actually, it was November, 4.
KM> I was assigned half of the HTTPbis docs to review in prep for the tele
chat, so the timeline may have been longer for the two volunteers who offered to
read through all of the documents for you.
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
_______________________________________________
Gen-art mailing list
Gen-art@ietf.org
https://www.ietf.org/mailman/listinfo/gen-art
