-----Original Message-----
From: Mark Nottingham [mailto:mnot(_at_)mnot(_dot_)net]
Sent: Sunday, January 29, 2012 6:50 PM
To: Stephen Hanna
Cc: Julian Reschke;
draft-nottingham-http-new-status(_at_)tools(_dot_)ietf(_dot_)org;
secdir(_at_)ietf(_dot_)org; ietf(_at_)ietf(_dot_)org
Subject: Re: secdir review of draft-nottingham-http-new-status-03
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/