Re: new version trusted-proxy20 draft

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?

>
> /Sal
>
>
>>
>> On Wed, Feb 19, 2014 at 7:30 AM, Peter Lepeska <bizzbyster@gmail.com> wrote:
>>> My two takeaways from Zurich on trusted proxy were as follows:
>>>
>>> 1) We need to look at use cases of trusted proxy and seek alternative
>>> technologies. I've attempted to start this process on another thread, which
>>> I believe shows current (and future) alternatives are partial solutions that
>>> we can conclude are inadequate overall in delivering the functionality and
>>> performance users/admins/service providers demand.
>>> 2) Until someone proposes a UI for opt-in and opt-out of trusted proxy that
>>> is both user friendly and does not make MITM attacks (rogue trusted proxies)
>>> easier to execute, then the debate on this topic is at a standstill. I am
>>> working on ideas in this area but it will take more than just a few weeks.
>>> It would be really great if others got involved.
>>>
>>> Salvatore's draft has some really good ideas but it does not attempt to
>>> address #2 above, which most agreed was the sticking point on trusted proxy,
>>> which we distinguish from "secure proxy" by the fact that a trusted proxy
>>> can see https-schemed traffic in plaintext.
>>>
>>> Peter
>>>
>>>
>>> On Tue, Feb 18, 2014 at 11:54 PM, William Chan (陈智昌) <willchan@chromium.org>
>>> wrote:
>>>>
>>>> On Tue, Feb 18, 2014 at 8:18 PM, Paul Hoffman <paul.hoffman@gmail.com>
>>>> wrote:
>>>>> On Tue, Feb 18, 2014 at 6:02 PM, William Chan (陈智昌)
>>>>> <willchan@chromium.org>
>>>>> wrote:
>>>>>>
>>>>>>
>>>>>> And furthermore, I should add that I don't really think it's in the
>>>>>> users' interests to have an intermediary be able to snoop listen in on
>>>>>> all their https traffic. I don't really see the value for end users in
>>>>>> standardizing any mechanism for doing this. Is there any?
>>>>>
>>>>>
>>>>> This still comes back to the theory that a trusted, explicit firewall,
>>>>> such
>>>>> as a corporate firewall, should be able to snoop on all traffic leaving
>>>>> the
>>>>> protected network. There are plenty of good reasons to do this, and
>>>>> plenty
>>>>> of people who disagree that there are any possible reasons.
>>>>
>>>> Good point. This is a controversial topic that we're unlikely to see
>>>> consensus on in the near future. Let me ask another question. Is there
>>>> a user agent that plans on supporting this proposal? At the Zurich
>>>> interim, IIRC, Patrick (Firefox), Rob (IE/WinInet), and I (Chromium)
>>>> all said we do not support this. If that's in error, please speak up.
>>>> Otherwise, if no user agent plans on supporting this, I don't see the
>>>> value of standardizing this.
>>>>
>>>
>

Received on Thursday, 20 February 2014 00:40:51 UTC