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

[Stephen Hanna <[e-mail]>]

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.

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/
> 
>