Re: The future of forward proxy servers in an http/2 over TLS world

noted, I guess I should have stated "apart from basic connectivity" 
(CONNECT method).

My concern is that we have an impending train wreck relating to blocking 
sites.

My opinion is blocking will not stop, and that we would all benefit from 
a way of doing it that allows a good user experience, without 
compromising privacy unduly.

My question is whether this is something others agree on and whether we 
have enough determination to do anything about it.


------ Original Message ------
From: "Dave Dolson" <ddolson@sandvine.com>
To: "Adrien de Croy" <adrien@qbik.com>; "ietf-http-wg@w3.org" 
<ietf-http-wg@w3.org>
Sent: 15/02/2017 12:47:26 PM
Subject: Re: The future of forward proxy servers in an http/2 over TLS 
world

>Proxies may also provide anonymity, which can improve privacy.
>
>Depending, of course, whether you trust the server or the proxy more.
>
>
>
>From: Adrien de Croy
>Sent: Tuesday, February 14, 2017 5:41 PM
>To: ietf-http-wg@w3.org
>Reply To: Adrien de Croy
>Subject: The future of forward proxy servers in an http/2 over TLS 
>world
>
>
>At the moment, it feels like the functions provided by proxy servers 
>are being squeezed out by changes in the protocol.
>
>I can understand the desire for privacy, and we've had the argument 
>about whether it should be available to all or not too many times 
>already.
>
>However, there are other functions that a proxy is commonly used for 
>that are becoming impossible with the direction TLS, HTTPS HSTS, cert 
>pinning etc are going.
>
>Whilst I can understand a desire and need for privacy, an ability to be 
>able to go to a website without betraying which site you're going to 
>(e.g. see https://tools.ietf.org/html/draft-schwartz-dns-sni-01 
><https://tools.ietf.org/html/draft-schwartz-dns-sni-01>) there's 
>probably 1 remaining IMO critical bona fide purpose for a proxy which 
>is becoming very problematic for users.
>
>Blocking requests.
>
>So, do we feel there is still a place for blocking requests?  Our 
>customers still certainly want this.
>
>Currently the user experience is either appalling (generic connectivity 
>failure report which wastes a lot of user time), or requires deployment 
>of a MitM, which is being squeezed out as well.  We should be able to 
>do better, but it doesn't appear to be being addressed at all, and the 
>gulf is widening.
>
>I believe we need to put some time into working out how we can allow a 
>proxy to block requests without an awful user experience that costs 
>users and tech support countless hours to deal with.
>
>This means we have a need to be able to respond to CONNECT with a 
>denial, and some kind of message that can be displayed to the user.
>
>It may be that the only way this can be achieved is by the concept of a 
>trusted proxy.
>
>Otherwise if the group consensus is that requests should not be 
>blocked, we need to deal with the consequences of that.
>
>Adrien
>
>P.s. another key feature is caching, but that is becoming less useful 
>anyway.  Customers can often live without caching, they do not tolerate 
>being unable to block however.
>
>