Subject: HTTP/2.0 goal: polcy enforcement

From: "Adrien W. de Croy" <[email-masked]>
Date: Sun, 25 Mar 2012 20:24:01 +0000

Hi all
  
I think there's a goal that hasn't been stated for HTTP/2.0.  The 
ability to control and enforce acceptable use policy, as practised by 
countless enterprises.
  
Currently, HTTP is open enough that such control can be implemented.  
HTTPS poses several problems wrt this aim.
  
This requirement is real, and is not going to go away.
  
Adopting an SSL/TLS only option for any replacement protocol makes life 
difficult for 
  
a) proxy vendors (have to code MITM software)
b) their customers (have to deploy certificates to make MITM work)
  
For this reason alone I don't see SPDY in its current form as a viable 
successor to HTTP.
  
Since I believe the main reason to adopt TLS for SPDY was to enable 
"out of band" negotiation of which protocol was going to be used, then 
we would require another method for this.
  
Proxies are an important part of HTTP infrastructure, and wanted by 
customers.  Developing a successor to HTTP/1.1 without enabling 
reliable / simple proxy function would be a huge mistake IMO.
  
Willy / Amos, I'm keen to see what you guys come up with.  
  
Adrien

---

From: Adam Barth <[email-masked]>
Date: Sun, 25 Mar 2012 17:46:57 -0700

Don't these intermediaries need to support TLS anyway to enforce an
acceptable use policy on HTTPS traffic?

It's widely believed that encouraging the use of TLS will improve
security on the web.  Encouraging the use of TLS with HTTP/2.0 would
seem to be a net benefit to the world.

Adam

On Sun, Mar 25, 2012 at 1:24 PM, Adrien W. de Croy <[email-masked]> wrote:
> Hi all
>
> I think there's a goal that hasn't been stated for HTTP/2.0.  The ability to
> control and enforce acceptable use policy, as practised by countless
> enterprises.
>
> Currently, HTTP is open enough that such control can be implemented.  HTTPS
> poses several problems wrt this aim.
>
> Since I believe the main reason to adopt TLS for SPDY was to enable "out of
> band" negotiation of which protocol was going to be used, then we would
> require another method for this.
>
> customers.  Developing a successor to HTTP/1.1 without enabling reliable /
> simple proxy function would be a huge mistake IMO.
>

---

From: "Adrien W. de Croy" <[email-masked]>
Date: Mon, 26 Mar 2012 00:52:44 +0000

------ Original Message ------
From: "Adam Barth" <[email-masked]>
To: "Adrien W. de Croy" <[email-masked]>
Cc: "HTTP Working Group" <[email-masked]>
Sent: 26/03/2012 1:46:57 p.m.
Subject: Re: HTTP/2.0 goal: polcy enforcement
>acceptable use policy on HTTPS traffic?
mostly that's handled by CONNECT rather than MITM.
  
MITM is generally frowned upon, and seems IMO to be a bit fragile - it 
depends on the willingness of client and server vendors to continue to 
let it happen, which could be a political hot potato if there's ever 
any abuse.  It doesn't work with client certs either.
  
I'm all for using TLS everywhere (apart from the load), but proxies 
need access to raw payload.  That requirement isn't going away.  It 
would be more successful IMO to explicitly provide for it it than 
ignore it.  Hence a protocol that can ask a proxy to make a TLS 
connection on its behalf would be a better option IMO.

Adrien

---

From: Willy Tarreau <[email-masked]>
Date: Mon, 26 Mar 2012 06:11:02 +0200

> connection on its behalf would be a better option IMO.

+1 on the "GET https://"

> Adrien

Willy

---

From: "Poul-Henning Kamp" <[email-masked]>
Date: Mon, 26 Mar 2012 06:02:58 +0000

In message <em09ef4353-30f0-4c3a-bd0b-f9912deb7be4@BOMBED>, "Adrien W. de Croy"
 writes:

>need access to raw payload.  That requirement isn't going away.

As bad as the idea might be in philosophical terms, it is a requirement
that must be handled.

On the other hand, there is an equally strong, if not stronger,
requirement to know for sure that nobody is doing MITM on a session.

I think a right-ish solution is to have a error-response that informs
the client that proxy-use is mandatory and gives the coordinates
for contacting the proxy.

The client gets a dialog box and can decide if they want to submit
to the proxys policy, or if they want to postpone their activites
until they can get end-to-end-privacy.

-- 
Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
[email-masked]         | TCP/IP since RFC 956
FreeBSD committer       | BSD since 4.3-tahoe    
Never attribute to malice what can adequately be explained by incompetence.

---

From: Mike Belshe <[email-masked]>
Date: Mon, 26 Mar 2012 23:22:46 +0200

> until they can get end-to-end-privacy.

You can't stop SSL by blocking SPDY.

Twitter and Google are already 100% SSL.  Facebook is moving toward 100%
SSL and will be there soon.

Those who write proxies that wish to subvert the communications of the user
are going to have to get more sophisticated to keep doing what they do
today.

I'm in favor of the GET https:// and all other forms of explicit proxies
(where the user is opted in, or configured in through proxy-auto-config,
DHCP, etc).  The implicit proxies are on limited future life already, and
that has nothing to do with SPDY.

Mike