Julian,
I'm sure that in your view one sentence is adequate to explain
all the security implications of each status code. However,
you may want to consider that some readers may not have quite
the same deep grasp of the matter that you do. Therefore,
I think it would be wise to provide more explanation. Here's an
example for section 7.2 on status code 429 (Too Many Requests):
Section 7.2 429 Too Many Requests
While status code 429 can be helpful in figuring out why a
server is not responding to requests, it can also be harmful.
When a server is under attack or simply receiving a very
large number of requests from a single party, responding
to each of these requests with a 429 status code will consume
resources that could be better used in other ways. Therefore,
a server in such circumstances may choose to send a 429 status
code only the first time a client exceeds its limit and
ignore subsequent requests from this client until its limit
is no longer exceeded. Other approaches may also be employed.
As you can see, I described security problems that could occur
with this status code and explained how those problems can be
avoided or mitigated. While it's true that these problems
could occur when a more generic status code is used to handle
the case of "too many requests", that does not mean that they
are not relevant to this document. On the contrary, the fact
that this document is providing more detailed status codes
gives us the opportunity and one can argue the obligation to
provide more detailed security analysis relevant to these more
detailed status codes.
And I'm glad that you saw the value in my comment about
Appendix B!
Thanks,
Steve
-----Original Message-----
From: Julian Reschke [mailto:julian(_dot_)reschke(_at_)gmx(_dot_)de]
Sent: Friday, January 13, 2012 3:27 PM
To: Stephen Hanna
Cc: draft-nottingham-http-new-status(_at_)tools(_dot_)ietf(_dot_)org;
secdir(_at_)ietf(_dot_)org;
ietf(_at_)ietf(_dot_)org
Subject: Re: secdir review of draft-nottingham-http-new-status-03
On 2012-01-13 20:59, Stephen Hanna wrote:
I have reviewed this document as part of the security directorate's
ongoing effort to review all IETF documents being processed by the
IESG. These comments were written primarily for the benefit of the
security area directors. Document editors and WG chairs should treat
these comments just like any other last call comments.
This document specifies new HTTP status codes for a variety of
common situations. Although I am not an HTTP expert, it seems
to me that this document is clear, well-written, and reasonable.
+1
From a security perspective, this document seems to have little
impact either positive or negative. However, the Security
Considerations section does not meet our usual standards.
While the authors include a subsection on each new status code,
they do not explain clearly what the security implications are
for each status code and how any possible negative impacts
could be reduced.
In general, the proposed new codes just allow to describe a problem
more
clearly; previously, a more generic status code would have to be used.
As such, they do not change security at all.
Riccardo Bernardini already commented on this issue during
IETF LC. However, I do not agree with Mr. Bernardini that
sections 7.1 and 7.2 are not security related. Rather, the
security implications are just not clearly stated. For example,
section 7.2 points out that servers may not want to always
use the 429 status code when receiving too many requests
from one client. This has security implications in that
a server under attack with excessive requests from one
client may compound the problem by queuing 429 status codes
for every request from that client. However, this is not
stated explicitly in section 7.2. Fleshing out the subsections
"Servers are not required to use the 429 status code; when limiting
resource usage, it may be more appropriate to just drop connections, or
take other steps."
of section 7 (Security Considerations) should help solve the
problem by providing a clear description of security problems
related to these result codes and recommended mitigations.
Section 7.4 does a decent job of describing the problems
but fails to describe mitigations. I think that having the
client use HTTPS instead of HTTP for important requests
and limiting the effects of HTTP (not HTTPS) responses
is an obvious mitigation.
It's not the job of this spec to completely describe security
considerations with respect to captive portals.
All the spec does is defining a new status code that, when used, makes
captive portals a bit better to work with.
I do have a question about the issues raised in Appendix B.
These are all legitimate issues. However, it seems to me
that having status code 511 should help with these. A
Indeed; that's why 511 is there in the first place. The introduction to
Appendix B should state that.
...
Best regards, Julian
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf