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

[Mark Nottingham <[e-mail]>]

On 31/01/2012, at 2:05 AM, Stephen Hanna wrote:

> Mark,
> 
> I don't want to rehash the discussion that we've already had.
> Clearly, you prefer brevity while I would prefer education in
> this instance.
> 
> I can live with your text for status codes 428, 429, and 431. For
> 511, I don't think it's adequate to just say that big security
> issues already exist. You should at least give some suggestions
> for how to deal with them. For example, you could point out that
> most user agents include some indication of whether the server
> has been authenticated. For captive portals, this indication will
> generally not be displayed so the user receives some warning
> that the response did not come from the requested URL.

Based upon other feedback, I've already added:

   Also, note that captive portals using this status code on an SSL or
   TLS connection (commonly, port 443) will generate a certificate error
   on the client.

to Section 7.4; does that address your concern?

Regards,


> 
> Thanks,
> 
> Steve
> 
>> -----Original Message-----
>> From: Mark Nottingham [mailto:[e-mail]]
>> Sent: Sunday, January 29, 2012 6:50 PM
>> To: Stephen Hanna
>> Cc: Julian Reschke; [e-mail];
>> [e-mail]; [e-mail]
>> 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/
>> 
>> 
> 

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