RE: secdir review of draft-nottingham-http-new-status-03
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:m...@mnot.net] Sent: Sunday, January 29, 2012 6:50 PM To: Stephen Hanna Cc: Julian Reschke; draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.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
Re: secdir review of draft-nottingham-http-new-status-03
On 2012-01-30 16:05, 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. Are you referring to HTTPS? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-nottingham-http-new-status-03
Yes -Steve -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Monday, January 30, 2012 10:10 AM To: Stephen Hanna Cc: Mark Nottingham; draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: secdir review of draft-nottingham-http-new-status-03 On 2012-01-30 16:05, 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. Are you referring to HTTPS? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
Well, a) this doesn't help for non-HTTPS traffic, anb b) in case of a captive portal intercepting https traffic, we would expect a certificate error, no? Anyway; this is not a security consideration specific to 511, but applies to captive portals in general, no matter whether the new status code is used or not. As such, it *could* be added to Appendix B. Best regards, Julian On 2012-01-30 16:22, Stephen Hanna wrote: Yes -Steve -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Monday, January 30, 2012 10:10 AM To: Stephen Hanna Cc: Mark Nottingham; draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: secdir review of draft-nottingham-http-new-status-03 On 2012-01-30 16:05, 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. Are you referring to HTTPS? Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
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:m...@mnot.net] Sent: Sunday, January 29, 2012 6:50 PM To: Stephen Hanna Cc: Julian Reschke; draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.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
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/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
On 14/01/2012, at 6:59 AM, Stephen Hanna wrote: I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A browser or non-browser application could recognize status code 511 as an indication that a captive portal is in use and avoid capturing favicons, looking for P3P files, and doing other things that should wait until after the captive portal is blocking access. When the original website stops returning 511, such activities could resume. I may be wrong in suggesting these ideas but if not it would be good to note them here. I've added a note linking the issues to 511 more explicitly. Thanks, -- Mark Nottingham http://www.mnot.net/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
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/ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
secdir review of draft-nottingham-http-new-status-03
I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A browser or non-browser application could recognize status code 511 as an indication that a captive portal is in use and avoid capturing favicons, looking for P3P files, and doing other things that should wait until after the captive portal is blocking access. When the original website stops returning 511, such activities could resume. I may be wrong in suggesting these ideas but if not it would be good to note them here. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: secdir review of draft-nottingham-http-new-status-03
On 2012-01-13 20:59, Stephen Hanna wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. +1 From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. In general, the proposed new codes just allow to describe a problem more clearly; previously, a more generic status code would have to be used. As such, they do not change security at all. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections 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. of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. It's not the job of this spec to completely describe security considerations with respect to captive portals. All the spec does is defining a new status code that, when used, makes captive portals a bit better to work with. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A Indeed; that's why 511 is there in the first place. The introduction to Appendix B should state that. ... Best regards, Julian ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: secdir review of draft-nottingham-http-new-status-03
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. And I'm glad that you saw the value in my comment about Appendix B! Thanks, Steve -Original Message- From: Julian Reschke [mailto:julian.resc...@gmx.de] Sent: Friday, January 13, 2012 3:27 PM To: Stephen Hanna Cc: draft-nottingham-http-new-sta...@tools.ietf.org; sec...@ietf.org; ietf@ietf.org Subject: Re: secdir review of draft-nottingham-http-new-status-03 On 2012-01-13 20:59, Stephen Hanna wrote: I have reviewed this document as part of the security directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written primarily for the benefit of the security area directors. Document editors and WG chairs should treat these comments just like any other last call comments. This document specifies new HTTP status codes for a variety of common situations. Although I am not an HTTP expert, it seems to me that this document is clear, well-written, and reasonable. +1 From a security perspective, this document seems to have little impact either positive or negative. However, the Security Considerations section does not meet our usual standards. While the authors include a subsection on each new status code, they do not explain clearly what the security implications are for each status code and how any possible negative impacts could be reduced. In general, the proposed new codes just allow to describe a problem more clearly; previously, a more generic status code would have to be used. As such, they do not change security at all. Riccardo Bernardini already commented on this issue during IETF LC. However, I do not agree with Mr. Bernardini that sections 7.1 and 7.2 are not security related. Rather, the security implications are just not clearly stated. For example, section 7.2 points out that servers may not want to always use the 429 status code when receiving too many requests from one client. This has security implications in that a server under attack with excessive requests from one client may compound the problem by queuing 429 status codes for every request from that client. However, this is not stated explicitly in section 7.2. Fleshing out the subsections 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. of section 7 (Security Considerations) should help solve the problem by providing a clear description of security problems related to these result codes and recommended mitigations. Section 7.4 does a decent job of describing the problems but fails to describe mitigations. I think that having the client use HTTPS instead of HTTP for important requests and limiting the effects of HTTP (not HTTPS) responses is an obvious mitigation. It's not the job of this spec to completely describe security considerations with respect to captive portals. All the spec does is defining a new status code that, when used, makes captive portals a bit better to work with. I do have a question about the issues raised in Appendix B. These are all legitimate issues. However, it seems to me that having status code 511 should help with these. A Indeed; that's why 511 is there in the first place. The introduction to Appendix B should state
