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

Mark Nottingham <mnot@mnot.net> Tue, 01 March 2016 03:16 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 EA0BA1A906D for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Feb 2016 19:16:07 -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 Gf6jE-j4JWqV for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Mon, 29 Feb 2016 19:16:06 -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 E5D641A9068 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Mon, 29 Feb 2016 19:16:00 -0800 (PST)
Received: from lists by frink.w3.org with local (Exim 4.80) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1aaaiZ-0001DL-Gb for ietf-http-wg-dist@listhub.w3.org; Tue, 01 Mar 2016 03:11:23 +0000
Resent-Date: Tue, 01 Mar 2016 03:11:23 +0000
Resent-Message-Id: <E1aaaiZ-0001DL-Gb@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 <mnot@mnot.net>) id 1aaaiU-0001CT-N7 for ietf-http-wg@listhub.w3.org; Tue, 01 Mar 2016 03:11:18 +0000
Received: from mxout-07.mxes.net ([216.86.168.182]) by maggie.w3.org with esmtps (TLS1.2:DHE_RSA_AES_256_CBC_SHA256:256) (Exim 4.80) (envelope-from <mnot@mnot.net>) id 1aaaiP-0004zz-9X for ietf-http-wg@w3.org; Tue, 01 Mar 2016 03:11:17 +0000
Received: from [192.168.1.101] (unknown [120.149.194.112]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 833F522E260; Mon, 29 Feb 2016 22:10:46 -0500 (EST)
Content-Type: text/plain; charset="windows-1252"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Mark Nottingham <mnot@mnot.net>
In-Reply-To: <56D503E8.3020200@treenet.co.nz>
Date: Tue, 01 Mar 2016 14:10:43 +1100
Cc: ietf-http-wg@w3.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <8AF0B2F7-561F-464B-840A-1F1B61F8370F@mnot.net>
References: <20160217003812.7831.6278.idtracker@ietfa.amsl.com> <56F7C2DF-06AA-477C-8515-C152CC3A56A4@mnot.net> <CA+9kkMC1Tce=eohXFSZfrD9cpJHOMOMKtoYqVbvUY3EwbboTqg@mail.gmail.com> <8BD7C79F-6882-43E5-B706-FA3335DBAA73@mnot.net> <CA+9kkMC_y9Ubha4ESCBuzU85UUQs8K4VGme81kJmjx+2v_3cTw@mail.gmail.com> <0817613D-A09F-4FE3-B4D5-B78749D015B2@mnot.net> <56D503E8.3020200@treenet.co.nz>
To: Amos Jeffries <squid3@treenet.co.nz>
X-Mailer: Apple Mail (2.3112)
Received-SPF: pass client-ip=216.86.168.182; envelope-from=mnot@mnot.net; helo=mxout-07.mxes.net
X-W3C-Hub-Spam-Status: No, score=-8.3
X-W3C-Hub-Spam-Report: AWL=1.336, BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_DB=-1, W3C_IRA=-1, W3C_IRR=-3, W3C_WL=-1
X-W3C-Scan-Sig: maggie.w3.org 1aaaiP-0004zz-9X 299467322214e4e4e7bc03043e53531d
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/8AF0B2F7-561F-464B-840A-1F1B61F8370F@mnot.net>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/31124
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 1 Mar 2016, at 1:52 PM, Amos Jeffries <squid3@treenet.co.nz> wrote:
> 
> On 1/03/2016 1:38 p.m., Mark Nottingham wrote:
>> 
>>> On 1 Mar 2016, at 11:00 AM, Ted Hardie wrote:
>>> 
>>> On Mon, Feb 29, 2016 at 3:49 PM, Mark Nottingham wrote:
>>> 
>>>> The document says that "Clients MAY selectively support this
>>>> media type. For example, an implementation might deem it only
>>>> useful (or safe) in CONNECT requests."  Given the other
>>>> restrictions, I don't use case outside of CONNECT, and I would
>>>> normally say that you shouldn't send an accept header where
>>>> you're not willing to receive the type; am I missing some of your
>>>> thinking here?
>>> 
>>> Interception proxies.
>>> 
>>> So, a client should send this accept request with all queries in
>>> case there is a friendly enough man in the middle to tell them that
>>> the traffic is being prevented and why?  I can't picture that being
>>> the right trade-off, personally, but I'd be interested in whether
>>> this sounds plausible to other folk.
>> 
>> Yeah, I doubt it too. It could be that we end up specifying it just
>> for CONNECT.
>> 
>> I wanted to get an indication of implementer interest before I went
>> too far into tweaking it, though...
> 
> FWIW; The "Accept: */*" header which is already very popular covers all
> mime types including this one.
> 
> If we are intending this to be used to expose MITM in a clean way. Then
> it does need to be spec'd for use on any method even if doing the IETF
> thing of 'ignoring' MITM existence in the texts.
> 
> Also the worst display related issues are with browsers. Their current
> behaviour is to not show anything at all from a CONNECT response
> regardle of whether its an error or not.  So backward compatibility
> there is already a non-issue - the JSON payload will be silently dropped
> by the most problematic clients.

At the end of the day, an intercepting proxy can already inject anything into an unencrypted payload anyway, so I'm not sure this use case is going to be interesting. 

I'm sure some intercepting proxy folks would like to show something like this to the user for an encrypted stream, but that seems well out of scope for this spec. Anyway, having a mechanism for the proxy to talk to the user when it's legitimately configured instead of intercepting might encourage more people to deploy non-intercepting proxies :)

So, I think I'll adjust the language in the draft to make this specific to CONNECT.

Cheers and thanks for the feedback,

--
Mark Nottingham   https://www.mnot.net/