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

[Stephen Hanna <[e-mail]>]

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:[e-mail]]
> Sent: Friday, January 13, 2012 3:27 PM
> To: Stephen Hanna
> Cc: [e-mail]; [e-mail];
> [e-mail]
> 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