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