- From: Richard Wheeldon (rwheeldo) <rwheeldo@cisco.com>
- Date: Mon, 26 May 2014 03:21:25 +0000
- To: Salvatore Loreto <salvatore.loreto@ericsson.com>
- CC: "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
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. 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. 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, 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 03:21:54 UTC