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

> 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/

Received on Tuesday, 1 March 2016 03:11:18 UTC