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

From: Stephen Hanna <[email-masked]>
Date: Fri, 13 Jan 2012 14:59:53 -0500

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.

---

From: Stephen Hanna <[email-masked]>
Date: Fri, 13 Jan 2012 16:26:28 -0500

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:[email-masked]]
> Sent: Friday, January 13, 2012 3:27 PM
> To: Stephen Hanna
> Cc: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: secdir review of draft-nottingham-http-new-status-03
> 
> On 2012-01-13 20:59, Stephen Hanna wrote:
> +1
> 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.
> 
> "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."
> 
> 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.
> 
> Indeed; that's why 511 is there in the first place. The introduction to
> Appendix B should state that.
> 
> > ...
> 
> Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Fri, 13 Jan 2012 21:26:43 +0100

+1

> for each status code and how any possible negative impacts

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.

Best regards, Julian

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2012 10:36:27 +1100

> in suggesting these ideas but if not it would be good to

I've added a note linking the issues to 511 more explicitly. Thanks,

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

---

From: Mark Nottingham <[email-masked]>
Date: Wed, 25 Jan 2012 10:36:45 +1100

Sorry for the delay in responding; just back from holiday.

> provide more detailed security analysis relevant to these more

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.

---

From: Mark Nottingham <[email-masked]>
Date: Mon, 30 Jan 2012 10:50:02 +1100

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,

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 30 Jan 2012 10:05:32 -0500

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

> From: Mark Nottingham [mailto:[email-masked]]
> Sent: Sunday, January 29, 2012 6:50 PM
> To: Stephen Hanna
> Cc: Julian Reschke; [email-masked];
> [email-masked]; [email-masked]
> 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.
> 
> > 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
> > 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.
> 
> > 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.
> >
> >
> > --

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jan 2012 16:09:56 +0100

> that the response did not come from the requested URL.

Are you referring to HTTPS?

Best regards, Julian

---

From: Stephen Hanna <[email-masked]>
Date: Mon, 30 Jan 2012 10:22:05 -0500

Yes

-Steve

> Sent: Monday, January 30, 2012 10:10 AM
> To: Stephen Hanna
> Cc: Mark Nottingham; [email-masked];

---

From: Julian Reschke <[email-masked]>
Date: Mon, 30 Jan 2012 17:08:55 +0100

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

---

From: Mark Nottingham <[email-masked]>
Date: Tue, 31 Jan 2012 09:49:13 +1100

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