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:mnot@xxxxxxxx] >> Sent: Sunday, January 29, 2012 6:50 PM >> To: Stephen Hanna >> Cc: Julian Reschke; draft-nottingham-http-new-status@xxxxxxxxxxxxxx; >> secdir@xxxxxxxx; ietf@xxxxxxxx >> 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/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf