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/
- [secdir] secdir review of draft-nottingham-http-n… Stephen Hanna
- Re: [secdir] secdir review of draft-nottingham-ht… Stephen Hanna
- Re: [secdir] secdir review of draft-nottingham-ht… Julian Reschke
- Re: [secdir] secdir review of draft-nottingham-ht… Mark Nottingham
- Re: [secdir] secdir review of draft-nottingham-ht… Mark Nottingham
- Re: [secdir] secdir review of draft-nottingham-ht… Mark Nottingham
- Re: [secdir] secdir review of draft-nottingham-ht… Stephen Hanna
- Re: [secdir] secdir review of draft-nottingham-ht… Julian Reschke
- Re: [secdir] secdir review of draft-nottingham-ht… Stephen Hanna
- Re: [secdir] secdir review of draft-nottingham-ht… Julian Reschke
- Re: [secdir] secdir review of draft-nottingham-ht… Mark Nottingham