Re: ext#9: OppSec and Proxies

Amos Jeffries <squid3@treenet.co.nz> Tue, 29 July 2014 11:34 UTC

Return-Path: <ietf-http-wg-request@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB7361B280C for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Jul 2014 04:34:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.903
X-Spam-Level:
X-Spam-Status: No, score=-6.903 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9pG9hloGcQPS for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Tue, 29 Jul 2014 04:34:23 -0700 (PDT)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 206EE1B27ED for <httpbisa-archive-bis2Juki@lists.ietf.org>; Tue, 29 Jul 2014 04:34:19 -0700 (PDT)
Received: from lists by frink.w3.org with local (Exim 4.72) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1XC5d0-0001Cm-4V for ietf-http-wg-dist@listhub.w3.org; Tue, 29 Jul 2014 11:31:34 +0000
Resent-Date: Tue, 29 Jul 2014 11:31:34 +0000
Resent-Message-Id: <E1XC5d0-0001Cm-4V@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XC5ch-0001Bi-Vo for ietf-http-wg@listhub.w3.org; Tue, 29 Jul 2014 11:31:16 +0000
Received: from 121-99-228-82.static.orcon.net.nz ([121.99.228.82] helo=treenet.co.nz) by maggie.w3.org with esmtp (Exim 4.72) (envelope-from <squid3@treenet.co.nz>) id 1XC5cg-00031o-VT for ietf-http-wg@w3.org; Tue, 29 Jul 2014 11:31:15 +0000
Received: from [192.168.0.6] (121-99-61-110.bng1.tvc.orcon.net.nz [121.99.61.110]) by treenet.co.nz (Postfix) with ESMTP id 852C4E6FBD for <ietf-http-wg@w3.org>; Tue, 29 Jul 2014 23:30:44 +1200 (NZST)
Message-ID: <53D785E1.50503@treenet.co.nz>
Date: Tue, 29 Jul 2014 23:30:41 +1200
From: Amos Jeffries <squid3@treenet.co.nz>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: ietf-http-wg@w3.org
References: <979C18AF-E6A3-49E2-A8C2-4D5E6CBE6470@mnot.net>
In-Reply-To: <979C18AF-E6A3-49E2-A8C2-4D5E6CBE6470@mnot.net>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
Received-SPF: pass client-ip=121.99.228.82; envelope-from=squid3@treenet.co.nz; helo=treenet.co.nz
X-W3C-Hub-Spam-Status: No, score=-3.4
X-W3C-Hub-Spam-Report: AWL=-3.398, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, TVD_RCVD_IP=0.001
X-W3C-Scan-Sig: maggie.w3.org 1XC5cg-00031o-VT 54fdbd966e01b3bee623c9a631152e22
X-Original-To: ietf-http-wg@w3.org
Subject: Re: ext#9: OppSec and Proxies
Archived-At: <http://www.w3.org/mid/53D785E1.50503@treenet.co.nz>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/26422
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <http://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>

On 29/07/2014 6:38 p.m., Mark Nottingham wrote:
> <https://github.com/httpwg/http-extensions/issues/9>
> 
> We discussed this issue in Toronto, and the sense of the room there was to close this issue with no action, since there are a lot of different scenarios for how a client uses a proxy, as well as different kinds of proxies which might cause clients to do different things.
> 
> Any more discussion?

If I am understanding the term "OppSec" correctly (does it still match
the millitary meaning?) then the administrators OPSEC policy itself
should be detailing these things, not HTTP spec.

All HTTP spec has to do is provide flexibility in access (CONNECT,
Upgrade, ALPN, Alt-Svc - good) and security operations (TLS, nothing,
home-grown message signatures - reasonable) which the policy selects
from. The onus is largely on implementations to retain interoperability
when such a policy prohibits or mandates certain traffic usage (within
HTTP spec).

For example Chrome by rejecting CONNECT+Upgrade and plain-text HTTP/2
has effectively omitted itself from several OpSec policy groups which
require open and/or recorded traffic within a network. The jail and
school controlled-network scenarios being the most well-known of these.

Amos