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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf