I haven't heard any further response. After a reminder from a Security AD, I took another look at the spec.
E.g., the current Security Considerations for 428: > The 428 status code is optional; clients cannot rely upon its use to prevent > "lost update" conflicts. Like many of the status codes, that's already a risk inherent in using HTTP today; we're effectively just noting that we can't force implementations to use the new status code retroactively, so they can't use the publication of this document as a magical flag day. As such, not much more can be said; the only way that people can further mitigate the risks of lost updates is to have a private, out-of-band agreement to use 429, and I *don't* think that's something we should be encouraging. For 429, I've changed to: > When a server is under attack or just receiving a very large number of > requests from a single party, responding to each with a 429 status code will > consume resources. > > Therefore, 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. 431 says: > Servers are not required to use the 431 status code; when under attack, it > may be more appropriate to just drop connections, or take other steps. What else should be said here? This specification is not a treatise on dealing with denial-of-service attacks; all that it notes is that servers aren't required to use the status code. Finally, 511 says: > In common use, a response carrying the 511 status code will not come from the > origin server indicated in the request's URL. This presents many security > issues; e.g., an attacking intermediary may be inserting cookies into the > original domain's name space, may be observing cookies or HTTP authentication > credentials sent from the user agent, and so on. However, these risks are not > unique to the 511 status code; in other words, a captive portal that is not > using this status code introduces the same issues. Are there other specific threats you're aware of here? Regards, On 25/01/2012, at 10:36 AM, Mark Nottingham wrote: > 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/ > > > -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Ietf mailing list [email protected] https://www.ietf.org/mailman/listinfo/ietf
