Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt

"Thomas Mangin" <thomas.mangin@exa-networks.co.uk> Wed, 02 March 2016 09:30 UTC

Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@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 847841AC3A7 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Mar 2016 01:30:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.006, 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 k-i3ZzyxfcNy for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Wed, 2 Mar 2016 01:30:23 -0800 (PST)
Received: from frink.w3.org (frink.w3.org [128.30.52.56]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8DAAE1AC3AB for <httpbisa-archive-bis2Juki@lists.ietf.org>; Wed, 2 Mar 2016 01:30:23 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1ab32O-0007fj-8R for ietf-http-wg-dist@listhub.w3.org; Wed, 02 Mar 2016 09:25:44 +0000
Resent-Date: Wed, 02 Mar 2016 09:25:44 +0000
Resent-Message-Id: <E1ab32O-0007fj-8R@frink.w3.org>
Received: from maggie.w3.org ([128.30.52.39]) by frink.w3.org with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from <thomas.mangin@exa-networks.co.uk>) id 1ab32J-0007eG-93 for ietf-http-wg@listhub.w3.org; Wed, 02 Mar 2016 09:25:39 +0000
Received: from out-1.mail.exa.net.uk ([82.219.4.129]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <thomas.mangin@exa-networks.co.uk>) id 1ab32D-0006cw-Ct for ietf-http-wg@w3.org; Wed, 02 Mar 2016 09:25:38 +0000
Received: from smtp-2.mail.exa.net.uk (smtp-2.mail.exa.net.uk [82.219.5.2]) by out-1.mail.exa.net.uk (ExaSMTPD) with ESMTP id 125FD1C0058; Wed, 2 Mar 2016 09:25:09 +0000 (GMT)
Received: from smtp-2.mail.exa.net.uk (localhost [127.0.0.1]) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTP id F293E402D6; Wed, 2 Mar 2016 09:25:08 +0000 (GMT)
Received: from [192.168.1.210] (ptr-34.212.219.82.rev.exa.net.uk [82.219.212.34]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: thomas@mangin.com) by smtp-2.mail.exa.net.uk (ExaSMTPD) with ESMTPSA; Wed, 2 Mar 2016 09:25:08 +0000 (GMT)
From: Thomas Mangin <thomas.mangin@exa-networks.co.uk>
To: hurtta@siilo.fmi.fi
Cc: Mark Nottingham <mnot@mnot.net>, HTTP WG <ietf-http-wg@w3.org>, Amos Jeffries <squid3@treenet.co.nz>, Kari Hurtta <hurtta-ietf@elmme-mailer.org>
Date: Wed, 02 Mar 2016 09:25:06 +0000
Message-ID: <DC6A5E50-5F88-474E-B563-FBD7F464FBE8@exa-networks.co.uk>
In-Reply-To: <201603020508.u2258kdD032054@shell.siilo.fmi.fi>
References: <8AF0B2F7-561F-464B-840A-1F1B61F8370F@mnot.net> <20160301050755.8E4D9365C@welho-filter2.welho.com> <20160301052245.D97763DF4@welho-filter4.welho.com> <22B52B27-29E3-4107-A0AA-1A5ACFB9E0FA@exa-networks.co.uk> <201603020508.u2258kdD032054@shell.siilo.fmi.fi>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Mailer: MailMate (1.9.4r5226)
X-Virus-Scanned: clamav-milter 0.98.7 at out-2-2.mail.exa.net.uk
X-Virus-Status: Clean
Received-SPF: pass client-ip=82.219.4.129; envelope-from=thomas.mangin@exa-networks.co.uk; helo=out-1.mail.exa.net.uk
X-W3C-Hub-Spam-Status: No, score=-4.6
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1ab32D-0006cw-Ct 252a338ffe6fb45e52d111519cedb1f1
X-Original-To: ietf-http-wg@w3.org
Subject: Re: New Version Notification for draft-nottingham-proxy-explanation-00.txt
Archived-At: <http://www.w3.org/mid/DC6A5E50-5F88-474E-B563-FBD7F464FBE8@exa-networks.co.uk>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31143
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>

Hi Kari,

I can see value in using a ‘secret’ between the client and proxy to 
validate the source of the reply.

If used with the CONNECT verb, there is no risk of the header carrying 
this information to be be passed on to the origin. However, if allowed 
through HTTP, any header would pass through towards the origin and then 
could be used by another non-configured proxy down the line. This could 
be mitigated by mandating a draft aware proxy to block any 
json+explaination response messages coming back towards the client.

Obviously this would not protect the client if a MITM attack is 
performed between the client and the proxy (i.e. most likely within the 
LAN where it should be mitigated at network level), but it would prevent 
interference ‘down the line’ where interference risks are greater.

Alternatively, draft support for HTTP could be negotiated using a 
message, using a new verb or muffing the semantic of an existing one 
like OPTIONS, the client is able at any time to issue a new command to 
renew the secret. In this scenario, the header would only be included if 
support is negotiated.

Thomas

> Register new header field for that nonce.
>
> Browser may include that on request when it is using proxy:
>
> New-header-field: nonce-value
> Connection: new-header-field
>
> Connection header field prevents origin server seeing
> this (if proxy follows HTTP/1.1 -- I do not know how
> this play with HTTP/2, but HTTP/2 is likely to be used
> only  with encrypted connections / with CONNECT method. )
>
> Given nonce-value can be included to 
> application/proxy-explanation+json
> as own member.
>
> ( Header field name should be something short like
>   'proxy-nonce', I think. )
>
> | Clients SHOULD indicate that they support this media type by 
> including it
> | in the field-value of the Accept request header
> | field [RFC7231] of all supported requests.
>
> To reduce fingerprinting and request size, browser probably use just 
> */* as
> Accept -header value.
>
> ( I notice that also this new nonce header field ('proxy-nonce' for 
> example)
>   may work as indicator that application/proxy-explanation+json is 
> supported
>   by browser. )
>
> / Kari Hurtta