W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2014

Re: explicitly authenticated proxy: new draft

From: Salvatore Loreto <salvatore.loreto@ericsson.com>
Date: Mon, 26 May 2014 10:41:32 +0000
To: "Richard Wheeldon (rwheeldo)" <rwheeldo@cisco.com>
CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
Message-ID: <A74FEDC6-1081-4E32-BC7B-088FDD0B209D@ericsson.com>
Hi Richard

thanks for reading the draft and providing your comments

On May 26, 2014, at 6:21 AM, Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com> wrote:

> Sorry for taking so long to get round to this. I've finally read through it. Whilst I fully appreciate the effort in trying to address the proxy cases, I'm a little bit concerned that by limiting it in scope to HTTP-only URLs we're still leaving the elephant in the room of organization-based HTTPS Inspection == MITM attack largely unaddressed.

that has been intentionally left out, as it is a subject that touch several protocols not only HTTP
and would require at least IMO some not trivial changes in the Web Architecture as well as in the
https:// URI semantic


> Also, I'd like to see an alteration such that either end-point could accept or reject connections based on TLS properties of the other - which is currently (and still in your draft) impossible.

While I understand the importance of involving both the ends in the scenario like the organisation-based HTTPS Inspection
you have in mind,

I do not think it is necessary in the scenario where the http:// URI traffic is transported over TLS, for several reasons.
The first one is that the http:// URI semantic does not mandate end-to-end security/privacy/confidentiality 
so if a WebSite decide to distribute a resource as http:// it implicitly provides consent for that resource to pass true
intermediaries and eventually to be cached 

> However, addressing these might put this in the scope of the TLS WG rather than the HTTP one but that's not my call to make.


> 
> It's a bit of a minor point, but I also find the use of "h2c" in a TLS negotiation ugly. Assuming that the c in h2c implies clear text, using it for an encrypted channel seems to be asking for confusion,

my reading is that h2c implies transport of http:// uri traffic that is a slightly different interpretation.
However I am fully aware that different people have different opinion and that the Opportunistic Encryption proposal suggest to use h2
for http:// uri traffic transported over opportunistic unauthenticated TLS

br
Salvatore

> 
> Richard
> 
> -----Original Message-----
> From: Salvatore Loreto [mailto:salvatore.loreto@ericsson.com] 
> Sent: 05 May 2014 07:50
> To: ietf-http-wg@w3.org
> Subject: explicitly authenticated proxy: new draft
> 
> 
> we have produced a new draft that proposes the definition of an Explicitly Authenticated Proxy as intermediary of normally unprotected "http://" URI scheme requests and responses of HTTP2 traffic.
> 
> The Explicitly Authenticated Proxy is defined as a message forwarding agent that  is selected, with explicit user's consent, and configured by the user agent to receive exclusively "http" URI scheme requests and attempt to satisfy those requests on behalf of the user agent.  
> A client is connected to an Explicitly Authenticated Proxy through an authenticated TLS secured connection.
> 
> The document describes also a method for a user agent to automatically discover and authenticate, and for an user to provide consent for an Explicitly Authenticated Proxy. 
> This enables proxies communication to be encrypted and authenticated, explicitly acknowledged by the user agent and visible to the server end point.
> 
> 
> URL:            http://www.ietf.org/internet-drafts/draft-loreto-httpbis-explicitly-auth-proxy-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-loreto-httpbis-explicitly-auth-proxy/
> Htmlized:       http://tools.ietf.org/html/draft-loreto-httpbis-explicitly-auth-proxy-00
> 
> 
> comments, suggestions and feedback are welcome
> 
> br
> Salvatore
> 
> 
Received on Monday, 26 May 2014 10:42:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 17:14:30 UTC