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
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf