Last Call Review of draft-nottingham-http-new-status-
review-nottingham-http-new-status-secdir-lc-hanna-2012-01-23-00

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.

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.

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

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
browser or non-browser application could recognize status
code 511 as an indication that a captive portal is in use
and avoid capturing favicons, looking for P3P files, and
doing other things that should wait until after the captive
portal is blocking access. When the original website stops
returning 511, such activities could resume. I may be wrong
in suggesting these ideas but if not it would be good to
note them here.