- From: Salvatore Loreto <salvatore.loreto@ericsson.com>
- Date: Mon, 24 Feb 2014 10:33:32 +0000
- To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
- CC: HTTP Working Group <ietf-http-wg@w3.org>
Hi Ilari thanks a lot for your comments see my answers in line On Feb 24, 2014, at 11:00 AM, Ilari Liusvaara <ilari.liusvaara@elisanet.fi> wrote: > On Fri, Feb 14, 2014 at 06:56:14PM +0000, Salvatore Loreto wrote: >> >> URL: http://www.ietf.org/internet-drafts/draft-loreto-httpbis-trusted-proxy20-01.txt > > Some comments: > > 1) As others have said, unnecressarily admitting to possible attackers > that connections aren't really protected is not a good idea. > > 2) The downgrade to HTTP/1.1 for proxy setup looks really odd, and > should be over TLS too. thanks to all the mail discussions, more thoughts and other chats on the issue I tend to agree that the captive proxy (i.e. section 3.2) solution with the downgrade to http/1.1 is not a so great proposal… especially compared to the trusted proxy one http://tools.ietf.org/html/draft-loreto-httpbis-trusted-proxy20-01#section-3.1 > > 3) Leaving manual configuration aside, there is certain merit to the > idea that network is able to force a proxy. OTOH, the arising security > issues aren't trivial (understatement). security issues are never trivial > > 4) One idea would be h2p / h2pxy / h2proxy protocol, which would be > HTTP/2 with some extensions for proxy operation, like additional > response codes, proxy being able to respond for itself, browser being > able to send request to proxy, proxy relaying certificate info, etc... > > 5) Regarding to usescases, protocol conforming to principle of > least priviledge and accomodiating all or even most of those (goes > up to "Tom's Rural broadband" right now) would likely be hideously > complicated mess of crypto. > > 6) Because of the last, one is pretty much limited to no trust (CONNECT) > or full trust (GET/POST/PUT). > > > -Ilari
Received on Monday, 24 February 2014 10:33:58 UTC