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

[Mark Nottingham <[e-mail]>]

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/