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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry for the delay in responding; just back from holiday.


On 14/01/2012, at 8:26 AM, Stephen Hanna wrote:

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

I'm really not sure I agree; the original text is:

   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.

If someone implementing a server doesn't understand that, I don't know that using more words really helps; it does, however, make it harder to find the words in the spec that *will* help.


--
Mark Nottingham   http://www.mnot.net/



_______________________________________________
Ietf mailing list
Ietf@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf


[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Fedora Users]