[secdir] secdir review of draft-nottingham-http-new-status-03
Stephen Hanna <shanna@juniper.net> Fri, 13 January 2012 20:01 UTC
Return-Path: <shanna@juniper.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 12B3221F8448; Fri, 13 Jan 2012 12:01:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.599
X-Spam-Level:
X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 H8DSbSPTIox0; Fri, 13 Jan 2012 12:01:13 -0800 (PST)
Received: from exprod7og127.obsmtp.com (exprod7og127.obsmtp.com [64.18.2.210]) by ietfa.amsl.com (Postfix) with ESMTP id AD57711E80AD; Fri, 13 Jan 2012 12:00:52 -0800 (PST)
Received: from P-EMHUB03-HQ.jnpr.net ([66.129.224.36]) (using TLSv1) by exprod7ob127.postini.com ([64.18.6.12]) with SMTP ID DSNKTxCNdI2mv9psM928MBHXSxY+WsabjS/h@postini.com; Fri, 13 Jan 2012 12:00:59 PST
Received: from p-emfe01-wf.jnpr.net (172.28.145.24) by P-EMHUB03-HQ.jnpr.net (172.24.192.37) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Jan 2012 11:59:55 -0800
Received: from EMBX01-WF.jnpr.net ([fe80::1914:3299:33d9:e43b]) by p-emfe01-wf.jnpr.net ([fe80::d0d1:653d:5b91:a123%11]) with mapi; Fri, 13 Jan 2012 14:59:54 -0500
From: Stephen Hanna <shanna@juniper.net>
To: "draft-nottingham-http-new-status@tools.ietf.org" <draft-nottingham-http-new-status@tools.ietf.org>, "secdir@ietf.org" <secdir@ietf.org>, "ietf@ietf.org" <ietf@ietf.org>
Date: Fri, 13 Jan 2012 14:59:53 -0500
Thread-Topic: secdir review of draft-nottingham-http-new-status-03
Thread-Index: AczSLeo7PTPAq42hRwirXy24basViA==
Message-ID: <AC6674AB7BC78549BB231821ABF7A9AEB82253AD14@EMBX01-WF.jnpr.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [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: Fri, 13 Jan 2012 20:01:14 -0000
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.
- [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