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 3C9E021F84FC; Tue, 24 Jan 2012 15:36:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.266
X-Spam-Level:
X-Spam-Status: No, score=-105.266 tagged_above=-999 required=5 tests=[AWL=-2.667, 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 chVduA0TifiU; Tue, 24 Jan 2012 15:36:45 -0800 (PST)
Received: from mxout-07.mxes.net (mxout-07.mxes.net [216.86.168.182]) by ietfa.amsl.com (Postfix) with ESMTP id 70EA321F84EA; Tue, 24 Jan 2012 15:36:32 -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 BC94922E1EB; Tue, 24 Jan 2012 18:36:30 -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: <AC6674AB7BC78549BB231821ABF7A9AEB82253AD14@EMBX01-WF.jnpr.net>
Date: Wed, 25 Jan 2012 10:36:27 +1100
Content-Transfer-Encoding: 7bit
Message-Id: <004F97D3-E825-4BD5-A761-1F047AAFB7AE@mnot.net>
References: <AC6674AB7BC78549BB231821ABF7A9AEB82253AD14@EMBX01-WF.jnpr.net>
To: Stephen Hanna <shanna@juniper.net>
X-Mailer: Apple Mail (2.1251.1)
Cc: "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:46 -0000

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/