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. _______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
