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

Mark Nottingham <mnot@mnot.net> Tue, 24 January 2012 23:36 UTC

Return-Path: <mnot@mnot.net>
X-Original-To: secdir@ietfa.amsl.com
Delivered-To: secdir@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9F1A11E80A0; Tue, 24 Jan 2012 15:36:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -104.885
X-Spam-Level:
X-Spam-Status: No, score=-104.885 tagged_above=-999 required=5 tests=[AWL=-2.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SmOL45xjf34N; Tue, 24 Jan 2012 15:36:49 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id DF17911E809A; Tue, 24 Jan 2012 15:36:48 -0800 (PST)
Received: from mnot-mini.mnot.net (unknown [118.209.240.235]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id E2B2322E257; Tue, 24 Jan 2012 18:36:46 -0500 (EST)
Mime-Version: 1.0 (Apple Message framework v1251.1)
Content-Type: text/plain; charset="us-ascii"
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <AC6674AB7BC78549BB231821ABF7A9AEB82253AE7B@EMBX01-WF.jnpr.net>
Date: Wed, 25 Jan 2012 10:36:45 +1100
Content-Transfer-Encoding: quoted-printable
Message-Id: <ED1DC359-2B17-4DA8-82C6-34E6DCDE918E@mnot.net>
References: <AC6674AB7BC78549BB231821ABF7A9AEB82253AD14@EMBX01-WF.jnpr.net> <4F109383.1090505@gmx.de> <AC6674AB7BC78549BB231821ABF7A9AEB82253AE7B@EMBX01-WF.jnpr.net>
To: Stephen Hanna <shanna@juniper.net>
X-Mailer: Apple Mail (2.1251.1)
Cc: Julian Reschke <julian.reschke@gmx.de>, "draft-nottingham-http-new-status@tools.ietf.org" <draft-nottingham-http-new-status@tools.ietf.org>, "ietf@ietf.org" <ietf@ietf.org>, "secdir@ietf.org" <secdir@ietf.org>
Subject: Re: [secdir] secdir review of draft-nottingham-http-new-status-03
X-BeenThere: secdir@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Security Area Directorate <secdir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/secdir>, <mailto:secdir-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/secdir>
List-Post: <mailto:secdir@ietf.org>
List-Help: <mailto:secdir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/secdir>, <mailto:secdir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 24 Jan 2012 23:36:50 -0000

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/