Re: new version trusted-proxy20 draft

OIC now. Thanks for the continued explanations. So, *if* (1) the user
agent is using opportunistic encryption to the origin *and if* (2) the
user agent opts into identifying MITM'able connections via ALPN
(through some unspecified UI, but one that might be agnostic to a
specific proxy), then a proxy can interpose itself in this fashion.
This is one method of discovering "secure" proxies.

I still don't understand why a user agent who supports HTTP requests
over unauthenticated TLS would want to identify the unauthenticated
TLS connections.

I've asked this before, and I still think it's a reasonable question.
Is there another vendor that wants to interop with this kind of proxy?
I'm asking this because I think that the purpose of standardizing such
a proposal is for interoperability across vendors, and I don't see the
point if the only implementations are Ericsson. But I may be
misunderstanding IETF policy here.

On Mon, Feb 24, 2014 at 12:57 PM, Salvatore Loreto
<salvatore.loreto@ericsson.com> wrote:
>
> On Feb 24, 2014, at 10:10 PM, William Chan (陈智昌) <willchan@chromium.org>
>  wrote:
>
> On Feb 24, 2014 11:57 AM, "Salvatore Loreto" <salvatore.loreto@ericsson.com>
> wrote:
>>
>>
>> On Feb 20, 2014, at 2:40 AM, William Chan (陈智昌) <willchan@chromium.org>
>> wrote:
>>
>> > On Wed, Feb 19, 2014 at 1:17 PM, Salvatore Loreto
>> > <salvatore.loreto@ericsson.com> wrote:
>> >>
>> >> On Feb 19, 2014, at 7:09 PM, William Chan (陈智昌) <willchan@chromium.org>
>> >> wrote:
>> >>
>> >>> Yeah, I'd like to see the "secure proxy" proposal separated out from
>> >>> the "trusted proxy" proposal. Let's move forward on the "secure proxy"
>> >>> one. I think the "trusted proxy" proposal is more complicated.
>> >>
>> >> I agree
>> >> and the draft is really proposing a "secure proxy" solution
>> >> in line with your definition of "secure proxy"
>> >>
>> >> indeed we are only proposing the possibility for the proxy to ask
>> >> consent
>> >> to opt in for http:// resources traffic
>> >
>> > Let's be clear, these are two different things. There's "secure proxy"
>> > which is securing the connection between the proxy and the client. I'm
>> > supportive of standardizing this. Then there's this opting into
>> > allowing http:// resources to be sniffed by signaling it via ALPN.
>> > What's the value proposition here? Why not issue the request to the
>> > proxy if you want to let it see it, just like we do for configured
>> > HTTP proxies?
>>
>> The value proposition here is that the user-agent does not have to be
>> configured to use the proxy, but is still able to take advantage of the
>> benefits it can provide.
>>
>> Think about the situation where you're on vacation in a remote area with
>> limited network resources. You wish to download an application.  The network
>> you're on has a caching proxy with the application cached.  You are able to
>> download the application faster, without tying up the resources in the
>> remote location.  That's the value proposition.
>>
>> I have also tried to explain those benefit here [1]
>>
>> And yes, the response is "well why not just configure the user-agent to
>> use the caching proxy?" Technically, this suggestion is completely correct,
>> but from a practical standpoint it makes no sense at all: users will not
>> manually configure address http proxies.
>> What we're proposing here is providing better security for the user-agent
>> (all content encrypted), preserving existing functionality (caching proxies,
>> virus scanning proxies, etc), and providing a mechanism where the user is
>> completely aware of any entity in the middle of their normal "http://"
>> traffic.
>
> Oic, I had assumed we were only talking about configured proxies. This makes
> more sense now, but I still disagree with it because it weakens
> opportunistic encryption (which I also don't support but I don't see why we
> should weaken that).
>
> Can you clarify whether the "secure" proxy (TLS to the proxy) part of your
> proposal is also for transparent proxies? I don't see how that would be
> possible, so I assume at least that part is for a configured proxy.
>
> let me start clarifying my previous answer, when I said
> "The value proposition here is that the user-agent does not have to be
> configured to use the proxy, but is still able to take advantage of the
> benefits it can provide."
>
> I meant "the user-agent does not have to be *manually configured* to use the
> proxy"
> the proposal DOES NOT propose a transparent proxy solution
>
> we are proposing that the proxy always advertises itself and its presence to
> the user
> the user is fully in control, she/he has to provide or deny consent to use
> the proxy…
> if the user provides consent to the proxy then and only then the proxy
> becomes configured within the user agent
>
> so the answer is YES we are talking about configured proxy
>
>>
>> Https traffic, is still there, providing private end to end encryption.
>
>

Received on Monday, 24 February 2014 21:26:06 UTC