Re: [secdir] secdir review of draft-nottingham-http-new-status-03

[Julian Reschke <[e-mail]>]

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