Re[2]: HTTP/2.0 goal: polcy enforcement

------ Original Message ------
From: "Adam Barth" <w3c@adambarth.com>
To: "Adrien W. de Croy" <adrien@qbik.com>
Cc: "HTTP Working Group" <ietf-http-wg@w3.org>
Sent: 26/03/2012 1:46:57 p.m.
Subject: Re: HTTP/2.0 goal: polcy enforcement
>Don't these intermediaries need to support TLS anyway to enforce an
>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
  
>
>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 <adrien@qbik.com> 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.
>>
>>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
>>
>>
>>
>

Received on Monday, 26 March 2012 00:53:23 UTC